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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines a call control protocol for use in the IP Multimedia (IM) Core Network (CN) subsystem 
based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP). 

The present document is applicable to: 

the interface between the User Equipment (UE) and the Call Session Control Function (CSCF); 

the interface between the CSCF and any other CSCF; 

the interface between the CSCF and an Application Server (AS); 

the interface between the CSCF and the Media Gateway Control Function (MGCF); 

the interface between the S-CSCF and the Multimedia Resource Function Controller (MRFC) 

the interface between the CSCF and the Breakout Gateway Control Function (BGCF); 

- the interface between the BGCF and the MGCF; 

the interface between the CSCF and an IBCF; 

the interface between the BGCF and any other BGCF; and 

the interface between the CSCF and an external Multimedia IP network. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP and SDP. Where this is not possible, extensions to SIP and SDP are 
defined within the present document. The document has therefore been structured in order to allow both forms of 
specification. 

As the IM CN subsystem is designed to interwork with different IP-Connectivity Access Networks (IP-CANs), the IP- 
CAN independent aspects of the IM CN subsystem are described in the main body and annex A of this specification. 
Aspects for connecting a UE to the IM CN subsystem through specific types of IP-CANs are documented separately in 
the annexes or in separate documents. 

NOTE: The present document covers only the usage of SIP and SDP to communicate with the enitities of the IM 
CN subsystem. It is possible, and not precluded, to use the capabilities of IP-CAN to allow a terminal 
containing a SIP UA to communicate with SIP servers or SIP UAs outside the IM CN subsystem, and 
therefore utilise the services provided by those SIP servers. The usage of SIP and SDP for communicating 
with SIP servers or SIP UAs outside the IM CN subsystem is outside the scope of the present document. 
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[100] draft-ietf-behave-rfc3489bis-04 (July 2006): "Simple Traversal Underneath Network Address 

Translators (NAT) (STUN)". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 
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UDP Through NAT (STUN)". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Entry point: In the case that "border control concepts", as specified in 3GPP TS 23.228 [7], are to be applied in 
an IM CN subsystem, then these are to be provided by capabilities within the IBCF, and the IBCF 
acts as an entry point for this network (instead of the 1-CSCF). In this case the IBCF and the 1- 
CSCF can be co-located as a single physical node. If "border control concepts" are not applied, 
then the 1-CSCF is considered as an entry point of a network. If the P-CSCF is in the home 
network, then the 1-CSCF is considered as an entry point for this document. 

Exit point: If operator preference requires the application of "border control concepts" as specified in 

3GPP TS 23.228 [7], then these are to be provided by capabilities within the IBCF, and requests 
sent towards another network are routed via a local network exit point (IBCF), which will then 
forward the request to the other network (discovering the entry point if necessary). 

Newly established set of security associations: Two pairs of IPsec security associations that have been created at 
the UE and/or the P-CSCF after the 200 (OK) response to a REGISTER request was received. 

Old set of security associations: Two pairs of IPsec security associations still in existence after another set of 
security associations has been established due to a successful authentication procedure. 

Temporary set of security associations: Two pairs of IPsec security associations that have been created at the UE 
and/or the P-CSCF, after an authentication challenge within a 401 (Unauthorized) response to a 
REGISTER request was received. The SIP level lifetime of such created security associations will 
be equal to the value of reg-await-auth timer. 

Integrity protected: See 3GPP TS 33.203 [19]. Where a requirement exists to send information "integrity 

protected" the mechanisms specified in 3GPP TS 33.203 [19] are used for sending the information. 
Where a requirements exists to check that information was received "integrity protected", then the 
information received is checked for compliance with the procedures as specified in 
3GPPTS 33.203 [19]. 

Instance ID: A URN that uniquely identifies a specific UA instance. 

Resource reservation: Mechanism for reserving bearer resources that is required for certain access technologies. 

Local preconditions: The indication of segmented status preconditions for the local reservation of resources as 
specified in RFC 3312 [30]. 

Alias SIP URI: A URl is an alias of another URI if the treatment of both URls is identical, i.e. both URIs belong 
to the same set of implicitly registered public user identities, have the same service profile, and 
both are either shared or not shared. 

Initial registration: The registration procedure for a public user identity initiated by the UE in the absence of any 
valid registration. 

Re-registration: The registration procedure initiated by the UE to refresh or update an already existing registration 
for a public user identity. 
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Registration of an additional public user identity: The registration procedure initiated by the UE to expHcitly 
register an additional pubUc user identity during the Hfe time of the registration of another 
registered public user identity, where both public user identities have the same contact address and 
P-CSCF. 

Emergency registration: A special registration that relates to an emergency public user identity. 

Initial emergency registration: An emergency registration that is also an initial registration. 

Emergency reregistration: An emergency registration that is also a reregistration. 

Back-to-Back User Agent (B2BUA): As given in RFC 3261 [26]. In addition, for the usage in the IM CN 

subsystem, a SIP element being able to handle a collection of "n" User Agents (behaving each one 
as UAC and UAS, according to SIP rules), which are linked by some application logic that is fully 
independent of the SIP rules. 

UE private IP address: It is assumed that the NAT device performs network address translation between a private 
and a public network with the UE located in the private network and the IM CN subsystem in the 
public network. The UE is assumed to be configured with a private IP address. This address will 
be denoted as UE private IP address. 

UE public IP address: The NAT device is assumed to be configured with one (or perhaps more) public 

address(es). When the UE sends a request towards the public network, the NAT replaces the 
source address in the IP header of the packet, which contains the UE private IP address, with a 
public IP addressed assigned to the NAT. This address will be denoted as UE public IP address. 

Encapsulating UDP header: For the purpose of performing UDP encapsulation according to RFC 3948 [63 A] 
each IPsec ESP packet is wrapped into an additional UDP header. This header is denoted as 
Encapsulating UDP header. 

Port_Uenc: In most residential scenarios, when the NAT device performs address translation, it also performs 

translation of the source port found in the transport layer (TCP/UDP) headers. Following 
RFC 3948 [63 A], the UE will use port 4500 as source port in the encapsulating UDP header when 
sending a packet. This port is translated by the NAT into an arbitrarily chosen port number which 
is denoted as port_Uenc. 

For the purposes of the present document, the following terms and definitions given in RFC 1594 [20B]. 

Fully-Qualified Domain Name (FQDN) 

For the purposes of the present document, the following terms and definitions given in RFC 3261 [26] apply (unless 
otherwise specified see clause 6). 

Client 

Dialog 

Final response 

Header 

Header field 

Loose routeing 

Method 

Option-tag (see RFC 3261 [26] subclause 19.2) 

Provisional response 

Proxy, proxy server 

Recursion 

Redirect server 

Registrar 

Request 

Response 

Server 

Session 

(SIP) transaction 

Stateful proxy 

Stateless proxy 

Status-code (see RFC 3261 [26] subclause 7.2) 
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Tag (see RFC 3261 [26] subclause 19.3) 
Target Refresh Request 
User agent client (UAC) 
User agent server (UAS) 
User agent (UA) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [2] 
subclause 4.1.1.1 and subclause 4a.7 apply: 

Breakout Gateway Control Function (BGCF) 

Call Session Control Function (CSCF) 

Home Subscriber Server (HSS) 

Media Gateway Control Function (MGCF) 

Multimedia Resource Function Controller (MRFC) 

Multimedia Resource Function Processor (MRFP) 

Subscription Locator Function (SLF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [5] 
subclause 3.1 apply: 

Filter criteria 
Initial filter criteria 
Initial request 
Standalone transaction 
Subsequent request 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [7] 
subclauses 3.1, 4.3.3.1, 4.3.6, 4.6, 5.2, 5.4.12.1 and 5.10 apply: 

Border control concepts 

Geo-local service number 

Home-local service number 

Implicit registration set 

Interconnection Border Control Function (IBCF) 

Interrogating-CSCF (I-CSCF) 

IMS Application Level Gateway (IMS-ALG) 

Local service number 

IP-Connectivity Access Network (IP-CAN) 

Policy Decision Function (PDF) 

Private user identity 

Proxy-CSCF (P-CSCF) 

Public Service Identity (PSI) 

Public user identity 

Serving-CSCF (S-CSCF) 

Statically pre-configured PSI 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 23.167 [4B] apply: 

Emergency-CSCF (E-CSCF) 

Geographical location information, short form Geolocation 

Location identifier 

Location information 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 33.203 [19] apply: 

IM Subscriber Identity Module (ISIM) 
Protected server port 
Protected client port 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [1] apply: 

Universal Integrated Circuit Card (UICC) 
Universal Subscriber Identity Module (USIM) 
User Equipment (UE) 
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For the purposes of the present document, the following terms and definitions given in RFC 2401 [20A] Appendix A 
apply: 

Security association 

A number of different security associations exist within the IM CN subsystem and within the underlying access 
transport. Within this document this term specifically applies to either: 

i) the security association that exists between the UE and the P-CSCF. This is the only security association that has 
direct impact on SIP; or 

ii) the security association that exists between the WLAN UE and the PDG. This is the security association that is 
relevant to the discussion of Interworking WLAN as the underlying IP-CAN. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [IB] apply: 

WLAN UE 

3GPP AAA proxy 

3GPP AAA server 

Packet Data Gateway (PDG) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.234 [7 A] apply. 

Interworking WLAN 
For the purposes of the present document, the following terms and definitions given in ITU-T E.164 [57] apply: 

International public telecommunication number 

For the purposes of the present document, the following terms and definitions given in draft-ietf-ecrit-requirements [91] 
apply: 

Emergency service identifier 

Emergency Service Routeing Proxy (ESRP) 

Emergency service URN 

Public Safety Answering Point (PSAP) 

PSAP URI 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

Ixx A status-code in the range 101 through 199, and excluding 100 

2xx A status-code in the range 200 through 299 

AAA Authentication, Authorization and Accounting 

AS Application Server 

APN Access Point Name 

AUTN Authentication TokeN 

B2BUA Back-to-Back User Agent 

BGCF Breakout Gateway Control Function 

c conditional 

BRAS Broadband Remote Access Server 

CCF Charging Collection Function 

CDF Charging Data Function 

CDR Charging Data Record 

CK Ciphering Key 

CN Core Network 

CPC Calling Party Category 

CSCF Call Session Control Function 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

DOCSIS Data Over Cable Service Interface Specification 

DTD Document Type Definition 

EC Emergency Centre 
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ECF 


Event Charging Function 




E-CSCF 


Emergency CSCF 




ESRP 


Emergency Service Routeing Proxy 




FQDN 


Fully Qualified Domain Name 




GCID 


GPRS Charging Identifier 




GGSN 


Gateway GPRS Support Node 




GPRS 


General Packet Radio Service 




GRUU 


Globally Routable User agent URI 




HSS 


Home Subscriber Server 




i 


irrelevant 




IBCF 


Interconnection Border Control Function 




I-CSCF 


Interrogating CSCF 




ICID 


IM CN subsystem Charging Identifier 




IK 


Integrity Key 




IM 


IP Multimedia 




IMS 


IP Multimedia core network Subsystem 




IMS-ALG 


IMS Application Level Gateway 




IMSI 


International Mobile Subscriber Identity 




lOI 


Inter Operator Identifier 




IP 


Internet Protocol 




IP-CAN 


IP-Connectivity Access Network 




IPsec 


IP security 




IPv4 


Internet Protocol version 4 




IPv6 


Internet Protocol version 6 




ISC 


IP Multimedia Subsystem Service Control 




ISIM 


IM Subscriber Identity Module 




I-WLAN 


Interworking - WLAN 




IWF 


Interworking Function 




LRF 


Location Retrieval Function 




m 


mandatory 




MAC 


Message Authentication Code 




MCC 


Mobile Country Code 




MGCF 


Media Gateway Control Function 




MGW 


Media Gateway 




MNC 


Mobile Network Code 




MRFC 


Multimedia Resource Function Controller 




MRFP 


Multimedia Resource Function Processor 




n/a 
NAI 


not applicable 

Network Access Identifier 




NA(P)T 


Network Address (and Port) Translation 




NASS 


Network Attachement Subsystem 




NAT 


Network Address Translation 







optional 




OCF 


Online Charging Function 




P-CSCF 


Proxy CSCF 




PDF 


Policy Decision Function 




PDG 


Packet Data Gateway 




PDP 


Packet Data Protocol 




PDU 


Protocol Data Unit 




PIDF-LO 


Presence Information Data Format Location 


Object 


PLMN 


Public Land Mobile Network 




PSAP 


Public Safety Answering Point 




PSI 


Public Service Identity 




PSTN 


Public Switched Telephone Network 




QoS 


QuaUty of Service 




RAND 


RANDom challenge 




RES 


RESponse 




RTCP 


Real-time Transport Control Protocol 




RTP 


Real-time Transport Protocol 




S-CSCF 


Serving CSCF 




SCTP 


Stream Control Transmission Protocol 




SDP 


Session Description Protocol 
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SIP Session Initiation Protocol 

SLF Subscription Locator Function 

SQN SeQuence Number 

UA User Agent 

UAC User Agent Client 

UAS User Agent Server 

UDVM Universal Decompressor Virtual Machine 

UE User Equipment 

UICC Universal Integrated Circuit Card 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

URN Uniform Resource Name 

UDVM Universal Decompressor Virtual Machine 

USIM Universal Subscriber Identity Module 

WLAN Wireless Local Area Network 

X prohibited 

xDSL Digital Subscriber Line (all types) 

XMAC expected MAC 

XML extensible Markup Language 



3A Interoperability with different IP-CAN 

The IM CN subsystem can be accessed by UEs resident in different types of IP -CAN. The main body of this document, 
and annex A, are general to UEs and IM CN subsystems that are accessed using any type of IP -CAN. Requirements that 
are dependent on the type of IP-CAN are covered in annexes B, D and E, or in separate specifications. 



4 General 

4.1 Conformance of IM CN subsystem entities to SIP, SDP and 
other protocols 

SIP defines a number of roles which entities can implement in order to support capabilities. These roles are defined in 
annex A. 

Each IM CN subsytem functional entity using an interface at the Gm reference point, the Ma reference point, the Mg 
reference point, the Mi reference point, the Mj reference point, the Mk reference point, the Mm reference point, the Mr 
reference point and the Mw reference point, and also using the IP multimedia Subsystem Service Control (ISC) 
Interface, shall implement SIP, as defined by the referenced specifications in Annex A, and in accordance with the 
constraints and provisions specified in annex A, according to the following roles. 

The Gm reference point, the Ma reference point, the Mg reference point, the Mi reference point, the Mj reference point, 
the Mk reference point, the Mm reference point, the Mr reference point, the Mw reference point and the ISC reference 
point are defined in 3GPP TS 23.002 [2]. 

The User Equipment (UE) shall provide the User Agent (UA) role, with the exceptions and additional 
capabilities to SIP as described in subclause 5.1, with the exceptions and additional capabilities to SDP as 
described in subclause 6.1, and with the exceptions and additional capabilities to SigComp as described in 
subclause 8.L The UE shall also provide the access dependent procedures described in subclause B.2.2. 

The P-CSCF shall provide the proxy role, with the exceptions and additional capabilities to SIP as described in 
subclause 5.2, with the exceptions and additional capabilities to SDP as described in subclause 6.2, and with the 
exceptions and additional capabilities to SigComp as described in subclause 8.2. Under certain circumstances as 
described in subclause 5.2, the P-CSCF shall provide the UA role with the additional capabilities, as follows: 

a) when acting as a subscriber to or the recipient of event information; and 

b) when performing P-CSCF initiated dialog-release the P-CSCF shall provide the UA role, even when acting as 
a proxy for the remainder of the dialog. 
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The I-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in 

subclause 5.3. 

The S-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.4, and with the exceptions and additional capabilities to SDP as described in subclause 6.3. Under 
certain circumstances as described in subclause 5.4, the S-CSCF shall provide the UA role with the additional 
capabilities, as follows: 

a) the S-CSCF shall also act as a registrar. When acting as a registrar, or for the purposes of executing a third- 
party registration, the S-CSCF shall provide the UA role; 

b) as the notifier of event information the S-CSCF shall provide the UA role; 

c) when providing a messaging mechanism by sending the MESSAGE method, the S-CSCF shall provide the 
UA role; and 

d) when performing S-CSCF initiated dialog release the S-CSCF shall provide the UA role, even when acting as 
a proxy for the remainder of the dialog. 

The MGCF shall provide the UA role, with the exceptions and additional capabilities as described in 
subclause 5.5, and with the exceptions and additional capabilities to SDP as described in subclause 6.4. 

The BGCF shall provide the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.6. 

The AS, acting as terminating UA, or redirect server (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.1), shall 
provide the UA role, with the exceptions and additional capabilities as described in subclause 5.7.2, and with the 
exceptions and additional capabilities to SDP as described in subclause 6.6. 

- The AS, acting as originating UA (as defined in 3GPP TS 23.218 [5] subclause 9.1.1 .2), shall provide the UA 
role, with the exceptions and additional capabilities as described in subclause 5.7.3, and with the exceptions and 
additional capabilities to SDP as described in subclause 6.6. 

The AS, acting as a SIP proxy (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.3), shall provided the proxy 
role, with the exceptions and additional capabilities as described in subclause 5.7.4. 

The AS, performing 3rd party call control (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.4), shall provide 
the UA role, with the exceptions and additional capabilities as described in subclause 5.7.5, and with the 
exceptions and additional capabilities to SDP as described in subclause 6.6. 

NOTE 1: Subclause 5.7 and its subclauses define only the requirements on the AS that relate to SIP. Other 
requirements are defined in 3GPP TS 23.218 [5]. 

The AS, receiving third-party registration requests, shall provide the UA role, with the exceptions and additional 
capabilities as described in subclause 5.7. 

The MRFC shall provide the UA role, with the exceptions and additional capabilities as described in 
subclause 5.8, and with the exceptions and additional capabilities to SDP as described in subclause 6.5. 

The IBCF shall provide the proxy role, with the exceptions and additional capabilities to SIP as described in 
subclause 5.10, and with the exceptions and additional capabilities to SDP as described in subclause 6.6. If the 
IBCF provides an application level gateway functionality, then the IBCF shall provide the UA role, with the 
exceptions and additional capabilities to SIP as described in subclause 5.10, and with the exceptions and 
additional capabilities to SDP as described in subclause 6.6. If the IBCF provides screening functionality, then 
the IBCF may provide the UA role, with the exceptions and additional capabilities to SIP as described in 
subclause 5.10. 

The E-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.11. 

In addition to the roles specified above, the P-CSCF, the I-CSCF, the IBCF, the S-CSCF, the BGCF and the E-CSCF 
can act as a UA when providing server functionality to return a final response for any of the reasons specified in 
RFC 3261 [26]. 
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NOTE 2: Annex A can change the status of requirements in referenced specifications. Particular attention is drawn 
to table A.4 and table A. 162 for capabilities within referenced SIP specifications, and to table A. 3 17 and 
table A.328 for capabilities within referenced SDP specifications. The remaining tables build on these 
initial tables. 

NOTE 3: The allocated roles defined in this clause are the starting point of the requirements from the IETF SIP 
specifications, and are then the basis for the description of further requirements. Some of these extra 
requirements formally change the proxy role into a B2BUA. In all other respects other than those more 
completely described in subclause 5.2a P-CSCF implements proxy requirements. Despite being a B2BUA 
a P-CSCF does not implement UA requirements from the IETF RFCs, except as indicated in this 
specification, e.g., relating to registration event subscription. 

NOTE 4: Except as specified in clause 5 or otherwise permitted in RFC 3261, the functional entities providing the 
proxy role are intended to be transparent to data within received requests and responses. Therefore these 
entities do not modify message bodies. If local policy applies to restrict such data being passed on, the 
functional entity has to assume the UA role and reject a request, or if in a response and where such 
procedures apply, to pass the response on and then clear the session using the BYE method. 

All the above entities are functional entities that could be implemented in a number of different physical platforms 
coexisting with a number of other functional entities. The implementation shall give priority to transactions at one 
functional entity, e.g. that of the the E-CSCF, over non-emergency transactions at other entities on the same physical 
implementation. Such priority is similar to the priority within the functional entities themselves specified elsewhere in 
this document. 

Additional routeing functionality can be provided to support the ability for the IM CN subsystem to provide transit 
functionality as specified in Annex I. The additional routeing functionality shall assume the proxy role. 

4.2 URI and address assignments 

In order for SIP and SDP to operate, the following preconditions apply: 

1) I-CSCFs used in registration are allocated SIP URIs. Other IM CN subsystem entities may be allocated SIP 
URIs. For example sip:pcscf homel.net and sip:<impl-specific-info>@pcscf.homel.net are valid SIP URIs. If 
the user part exists, it is an essential part of the address and shall not be omitted when copying or moving the 
address. How these addresses are assigned to the logical entities is up to the network operator. For example, a 
single SIP URI may be assigned to all I-CSCFs, and the load shared between various physical boxes by 
underlying IP capabilities, or separate SIP URIs may be assigned to each I-CSCF, and the load shared between 
various physical boxes using DNS SRV capabilities. 

2) All IM CN subsystem entities are allocated IP addresses. For systems providing access to IMS using a fixed 
broadband interconnection, any IM CN subsystem entities can be allocated IPv4 only, IPv6 only or both IPv4 
and IPv6 addresses. Otherwise, systems shall support IP addresses as specified in 3GPP TS 23.221 [6] 
subclause 5.1. 

3) The subscriber is allocated a private user identity by the home network operator, and this is contained within the 
ISIM application, if present. Where no ISIM application is present but USIM is present, the private user identity 
is derived (see subclause 5. 1.1.1 A). This private user identity is available to the SIP application within the UE. 

NOTE: The SIP URIs can be resolved by using any of public DNSs, private DNSs, or peer-to-peer agreements. 

4) The subscriber is allocated one or more public user identities by the home network operator. The public user 
identity shall take the form of SIP URI as specified in RFC 3261 [26] or tel URI as specified in RFC 3966 [22]. 
At least one of the public user identities is a SIP URI and it is stored within the ISIM application, if ISIM 
application is present. Where no ISIM application is present but USIM is present, the UE derives a temporary 
public user identity (see subclause 5.1.1.1A). All registered public user identities are available to the SIP 
application within the UE, after registration. 

5) If the UE supports GRUU, then it shall have an Instance ID, in conformance with the mandatory requirements 
for Instance IDs specified in draft-ietf-sip-gruu [93] and draft-ietf-sip-outbound [92]. 

6) For each tel URI, there is at least one alias SIP URI in the set of implicitly registered public user identities that is 
used to implicitly register the associated tel URI. 
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7) The public user identities may be shared across multiple UEs. A particular public user identity may be 
simultaneously registered from multiple UEs that use different private user identities and different contact 
addresses. When reregistering and deregistering a given public user identity and associated contact address, the 
UE will use the same private user identity that it had used during the initial registration of the respective public 
user identity and associated contact address. If the tel URI is a shared public user identity, then the associated 
alias SIP URI is also a shared public user identity. Likewise, if the alias SIP URI is a shared public user identity, 
then the associated tel URI is also a shared public user identity. 

8) For the purpose of access to the IM CN subsystem, UEs are assigned IPv6 prefixes in accordance with the 
constraints specified in 3GPP TS 23.221 [6] subclause 5.1 (see subclause 9.2.1 for the assignment procedures). 
In the particular case of UEs accessing the IMS using a fixed broadband interconnection, UEs can be allocated 
IPv4 only, IPv6 only or both IPv4 and IPv6 addresses. 

9) For the purpose of emergency service, there are at least two emergency public user identities (as defined in 
3GPP TS 23.003 [3]) assigned to each UE, of which one is a tel URI and the second is its associated alias SIP 
URI. The emergency public user identities are not shared. 



4.2A Transport mechanisms 



This document makes no requirement on the transport protocol used to transfer signalling information over and above 
that specified in RFC 3261 [26] clause 18. However, the UE and IM CN subsystem entities shall transport SIP messages 
longer than 1300 bytes according to the procedures of RFC 3261 [26] subclause 18.1.1, even if a mechanism exists of 
discovering a maximum transmission unit size longer than 1500 bytes. 

NOTE: Support of SCTP as specified in RFC 4168 [96] is optional for IM CN subsystem entities implementing 
the role of a UA or proxy. SCTP transport between the UE and P-CSCF is not supported in the present 
document. Support of the SCTP transport is currently not described in 3GPP TS 33.203 [19]. 

For initial REGISTER requests, the UE and the P-CSCF shall apply port handling according to subclause 5.1.1.2 and 
subclause 5.2.2. 

The UE and the P-CSCF shall send and receive request and responses other than initial REGISTER requests on the 
protected ports as described in 3GPP TS 33.203 [19]. 

In case of an emergency session if the UE does not have sufficient credentials to authenticate with the IM CN 
subsystem and regulations allow, the UE and P-CSCF shall send request and responses other than initial REGISTER 
requests on non protected ports. 

4.3 Routeing principles of IIVI CN subsystem entities 

Each IM CN subsystem functional entity shall apply loose routeing policy as described in RFC 3261 [26], when 
processing a SIP request. In cases where the I-CSCF, IBCF, S-CSCF and the E-CSCF may interact with strict routers in 
non IM CN subsystem networks, the routeing procedures defined in RFC 3261 [26] that ensure interoperability with 
strict routers shall be used by the I-CSCF, IBCF, S-CSCF and E-CSCF. 

4.4 Trust domain 

RFC 3325 [34] provides for the existence and trust of an asserted identity within a trust domain. For the IM CN 
subsystem, this trust domain consists of the functional entities that belong to the same operator's network (P-CSCF, the 
E-CSCF, the I-CSCF, the IBCF, the S-CSCF, the BGCF. the MGCF, the MRFC, and all ASs that are included in the 
trust domain). Additionally, other IMS nodes that are not part of the same operator's domain may or may not be part of 
the trust domain, depending on whether an interconnect agreement exists with the remote network. SIP functional 
entities that belong to a network for which there is an interconnect agreement are part of the trust domain. ASs outside 
the operator's network can also belong to the trust domain if they have a trusted relationship with the home network. 
SIP functional entities within the trust domain will need to take an action on the removal of the P-Asserted-Identity 
header when SIP signalling crosses the boundary of the trust domain. 

NOTE 1: Whether any peer functional entity is regarded as part of the same operator's domain, and therefore part of 
the same trust domain, is dependent on operator policy which is preconfigured into each functional entity. 
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NOTE 2: For the purpose of this document., the PS AP is automatically regarded as being within the trust domain. 
This means that e.g. the handling of the P- Access-Network-Info header, P-Asserted-Identity header and 
the History-Info header will be as if the PS AP is within the trust domain, and these header fields will not 
be removed for trust domain issues. 

For the purpose of the P-Access-Network-Info header, a trust domain also applies. This trust domain is identical to that 
of the P-Asserted-Identity. For the P- Access-Network-Info header, subclause 5.4 also identifies additional cases for the 
removal of the header. 

NOTE 3: In addition to the procedures specified in clause 5, procedures of RFC 3325 [34] in relation to 

transmission of P-Asserted-Identity headers and their contents outside the trust domain also apply. 

According to RFC 4244 [66] subclause 3.3, the History-Info header can be restricted to specific domains. Therefore for 
the purpose of the History-Info header within this specification, a trust domain also applies. This trust domain is 
identical to that of the P-Asserted-Identity. For the History-Info header, subclause 5.4 also identifies additional cases for 
the removal of the header. SIP functional entities within the trust domain will need to take an action on the removal of 
the History-Info header when SIP signalling crosses the boundary of the trust domain. 

4.5 Charging correlation principles for IM CN subsystems 

4.5.1 Overview 

This subclause describes charging correlation principles to aid with the readability of charging related procedures in 
clause 5. See 3GPP TS 32.240 [16] and 3GPP TS 32.260 [17] for further information on charging. 

The IM CN subsystem generates and retrieves the following charging correlation information for later use with offline 
and online charging: 

1 . IM CN subsystem Charging Identifier (ICID); 

2. Access network charging information; 

3. Inter Operator Identifier (lOI); 

4. Charging function addresses: 

a. Charging Data Function (CDF); 

b. Online Charging Function (OCF). 

How to use and where to generate the parameters in IM CN subsystems are described further in the subclauses that 
follow. The charging correlation information is encoded in the P-Charging-Vector header as defined in 
subclause 7.2A.5. The P-Charging-Vector header contains the following parameters: icid, access network charging 
information and ioi. 

The offline and online charging function addresses are encoded in the P-Charging-Function- Addresses as defined in 
RFC 3455 [52]. The P-Charging-Function- Addresses header contains the following parameters: "ccf" for CDF and 
"ecf for OCF. 

NOTE: P-Charging-Function- Addresses parameters were defined using previous terminology. 

4.5.2 IM CN subsystem charging identifier (ICID) 

The ICID is the session level data shared among the IM CN subsystem entities including ASs in both the calling and 
called IM CN subsystems. The ICID is used also for session unrelated messages (e.g. SUBSCRIBE request, NOTIFY 
request, MESSAGE request) for the correlation with CDRs generated among the IM CN subsystem entities. 

The first IM CN subsystem entity involved in a SIP transaction will generate the ICID and include it in the icid 
parameter of the P-Charging- Vector header in the SIP request. For a dialog relating to a session, this will be performed 
only on the INVITE request, for all other transactions, it will occur on each SIP request. See 3GPP TS 32.260 [17] for 
requirements on the format of ICID. The P-CSCF will generate an ICID for UE-originated calls. The I-CSCF will 
generate an ICID for UE-terminated calls if there is no ICID received in the initial request (e.g. the calling party 
network does not behave as an IM CN subsystem). The AS will generate an ICID when acting as an originating UA. 
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The MGCF will generate an ICID for PSTN/PLMN originated calls. Each entity that processes the SIP request will 
extract the ICID for possible later use in a CDR. The I-CSCF and S-CSCF are also allowed to generate a new ICID for 
UE-terminated calls received from another network. 

There is also an ICID generated by the P-CSCF with a REGISTER request that is passed in a unique instance of P- 
Charging- Vector header. The valid duration of the ICID is specified in 3GPP TS 32.260 [17]. 

The icid parameter is included in any request that includes the P-Charging- Vector header. However, the P-Charging- 
Vector (and ICID) is not passed to the UE. 

The ICID is also passed from the P-CSCF to the IP-CAN via PDF. The interface supporting this operation is outside the 
scope of this document. 

4.5.3 Access network charging information 

4.5.3.1 General 

The access network charging information are the media flow level data shared among the IM CN subsystem entities for 
one side of the session (either the calling or called side). GPRS charging information (GGSN identifier and PDP context 
information) is an example of access network charging information. 

4.5.3.2 Access network charging information 

The IP-CAN provides the access network charging information to the IM CN subsystem. This information is used to 
correlate IP -CAN CDRs with IM CN subsystem CDRs, i.e. the access network charging information is used to correlate 
the bearer level with the session level. 

The access network charging information is generated at the first opportunity after the resources are allocated at the IP- 
CAN. The access network charging information is passed from IP-CAN to P-CSCF via PDF, over the Go and Gq 
interfaces. Access network charging information will be updated with new information during the session as media 
flows are added or removed. The P-CSCF provides the access network charging information to the S-CSCF. The S- 
CSCF may also pass the information to an AS, which may be needed for online pre-pay applications. The access 
network charging information for the originating network is used only within that network, and similarly the access 
network charging information for the terminating network is used only within that network. Thus the access network 
charging information are not shared between the calling and called networks. The access network charging information 
is not passed towards the external ASs from its own network. 

The access network charging information is populated in the P-Charging- Vector header. 

4.5.4 Inter operator identifier (101) 

The Inter Operator Identifier (lOI) is a globally unique identifier to share between sending and receiving networks, 
service providers or content providers. 

The sending network populates the orig-ioi parameter of the P-Charging-Vector header in a request and thereby 
identifies the operator network from which the request originated. The term-ioi parameter is left out of the P-Charging- 
Vector header in this request. The sending network retrieves the term-ioi parameter from the P-Charging- Vector header 
within the message sent in response, which identifies the operator network from which the response was sent. 

The receiving network retrieves the orig-ioi parameter from the P-Charging-Vector header in the request, which 
identifies the operator network from which the request originated. The receiving network populates the term-ioi 
parameter of the P-Charging-Vector header in the response to the request, which identifies the operator network from 
which the response was sent. 

There are three types of lOI: 

Type 1 lOI, between the P-CSCF (possibly in the visited network) and the S-CSCF in the home network. This is 
exchanged in REGISTER requests and responses. 

Type 2 lOI, between the S-CSCF of the home originating network and the S-CSCF of the home terminating 
network or between the S-CSCF of the home originating network and the MGCF when a call/session is 
terminated at the PSTN/PLMN or between the MGCF and the S-CSCF of the home terminating network when a 
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call/session is originated from the PSTN/PLMN or with a PSI AS when accessed accross I-CSCF. This is 
exchanged in all session-related and session-unrelated requests and responses. For compatibility issues related to 
CS charging system behaviour simulation, the S-CSCF in the terminating network shall forward the orig-ioi 
parameter from the P-Charging- Vector header in the initial request, which identifies the operator network from 
which the request originated. 

Editor's Note: The solution documented above results in overloading of the lOI parameter to the AS add additional 
complexity to the billing system in identifying the required lOI pair, some investigation is still in progress 
to see if a simpler solution can be adopted that meets the requirements. 

Type 3 lOI, between the S-CSCF or I-CSCF of the home operator network and any AS. This is exchanged in all 
session-related and session-unrelated requests and responses. 

Each entity that processes the SIP request will extract the lOI for possible later use in a CDR. The valid duration of the 
lOI is specified in 3GPP TS 32.240 [16]. 



4.5.5 Charging function addresses 



Charging function addresses are distributed to each of the IM CN subsystem entities in the home network for one side 
of the session (either the calling or called side) and provide a common location for each entity to send charging 
information. Charging Data Function (CDF) addresses are used for offline billing. Online Charging Function (OCF) 
addresses are used for online billing. 

There may be multiple addresses for CDF and OCF addresses populated into the P-Charging-Function-Addresses 
header of the SIP request or response. The parameters are ccf and ecf for CDF and OCF, respectively. At least one 
instance of either ccf or ecf is required. If ccf address is included for offline charging, then a secondary ccf address may 
be included by each network for redundancy purposes, but the first instance of ccf is the primary address. If ecf address 
is included for online charging, then a secondary instance may also be included for redundancy. 

The CDF and/or OCF addresses are retrieved from an Home Subscriber Server (HSS) via the Cx interface and passed 
by the S-CSCF to subsequent entities. The charging function addresses are passed from the S-CSCF to the IM CN 
subsystem entities in its home network, but are not passed to the visited network or the UE. When the P-CSCF is 
allocated in the visited network, then the charging function addresses are obtained by means outside the scope of this 
document. The AS receives the charging function addresses from the S-CSCF via the ISC interface. CDF and/or OCF 
addresses may be allocated as locally preconfigured addresses. The AS can also retrieve the charging function address 
from the HSS via Sh interface. 

4.6 Support of local service numbers 

For the IM CN subsystem, the support of local service numbers is provided by an AS in the subscriber's home network 
as described in subclause 5.7.1.7. 



5 Application usage of SIP 

5.1 Procedures at the UE 

5.1 .1 Registration and authentication 

5.1.1.1 General 

The UE shall register public user identities (see table A.4/1 and dependencies on that major capability). 

In case a UE registers several public user identities at different points in time, the procedures to re-register, deregister 
and subscribe to the registration-state event package for these public user identities can remain uncoordinated in time. 

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT, the UE 
may need to modify the SIP contents according to the procedures described in either annex F or annex K. 
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5. 1.1.1 A Parameters contained in the ISIM 

The ISIM application shall always be used for IMS authentication, if it is present, as described in 3GPP TS 33.203 [19]. 

The ISIM is preconfigured with all the necessary parameters to initiate the registration to the IM CN subsystem. These 
parameters include: 

the private user identity; 

one or more public user identities; and 

the home network domain name used to address the SIP REGISTER request 
In case the UE is loaded with a UICC that does not contain the ISIM application, the UE shall: 

generate a private user identity; 

generate a temporary public user identity; and 

generate a home network domain name to address the SIP REGISTER request to; 

in accordance with the procedures in clause C.2. 

The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, UE- 
initiated deregistration. 

The UE shall not reveal to the user the temporary public user identity if the temporary public user identity is barred. The 
temporary public user identity is not barred if received by the UE in the P-Associated-URI header. 

If the UE is unable to derive the parameters in this subclause for any reason, then the UE shall not proceed with the 
request associated with the use of these parameters and will not be able to register to the IM CN subsystem. 

5.1 .1 .2 Initial registration 

The initial registration procedure consists of the UE sending an unprotected initial REGISTER request and, upon being 
challenged, sending the integrity protected REGISTER request. The UE can register a public user identity with its 
contact address at any time after it has acquired an IP address, discovered a P-CSCF, and established an IP -CAN bearer 
that can be used for SIP signalling. However, the UE shall only initiate a new registration procedure when it has 
received a final response from the registrar for the ongoing registration, or the previous REGISTER request has timed 
out. 

The UE shall send only the initial REGISTER requests to the port advertised to the UE during the P-CSCF discovery 
procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE 
shall send the initial REGISTER request to the SIP default port values as specified in RFC 3261 [26]. 

The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the 
Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A. A public user identity 
may be input by the end user. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) an Authorization header, with: 

the username directive, set to the value of the private user identity; 

the realm directive, set to the domain name of the home network; 

the uri directive, set to the SIP URI of the domain name of the home network; 

the nonce directive, set to an empty value; and 

the response directive, set to an empty value; 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URI that contains the public user identity to be registered; 
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d) a Contact header set to include SIP URI(s) containing the IP address of the UE in the hostport parameter or 
FQDN. If the UE supports GRUU, it shall include a +sip. instance parameter containing the instance ID. If the 
REGISTER request is protected by a security association, the UE shall also include the protected server port 
value in the hostport parameter; 

e) a Via header set to include the IP address or FQDN of the UE in the sent-by field. For the UDP, if the 
REGISTER request is protected by a security association, the UE shall also include the protected server port 
value in the sent-by field, while for the TCP, the response is received on the TCP connection on which the 
request was sent; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
association. For details on the selection of the port values see 3GPP TS 33.203 [19]. 

f) an Expires header, or the expires parameter within the Contact header, set to the value of 600 000 seconds as the 
value desired for the duration of the registration; 

NOTE 3: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) the Security-Client header field set to specify the security mechanism the UE supports, the IPsec layer 

algorithms the UE supports and the parameters needed for the security association setup. The UE shall support 
the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters 
needed for the security association setup is specified in Annex H of 3GPP TS 33.203 [19]. The UE shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPsec layer 
algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19], and shall announce 
support for them according to the procedures defined in RFC 3329 [48]; 

i) the Supported header containing the option tag "path", and if GRUU is supported, the option tag "gruu"; and 

j) if a security association exists, and if available to the UE (as defined in the access technology specific annexes 
for each access technology), a P-Access-Network-Info header set as specified for the access network technology 
(see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the expiration time of the registration for the public user identities found in the To header value; 

b) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header; 

NOTE 4: The UE can utilize additional URIs contained in the P-Associated-URI header, e.g. for application 
purposes. 

c) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI 
header; 

d) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs and standalone transactions; 

e) set the security association lifetime to the longest of either the previously existing security association lifetime (if 
available), or the lifetime of the just completed registration plus 30 seconds; and 

NOTE 5: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49]. 

f) find the Contact header within the response that matches the one included in the REGISTER request. If this 
contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, and the UE supports GRUU, then store the 
value of those parameters as the GRUUs for the UE in association with the public user identity that was 
registered. 
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When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in 

subclause 5.1.1.5.1. 

On receiving a 305 (Use Proxy) response to the initial REGISTER request, the UE shall: 

a) release all IP -CAN bearers used for the transport of media according to the procedures in subclause 9.2.2; 

b) initiate a new P-CSCF discovery procedure as described in subclause 9.2.1; 

c) select a P-CSCF address, which is different from the previously used address, from the address list; and 

d) perform the procedures for initial registration as described in subclause 5. 1 . 1 .2. 

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall: 

send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) or 
600 (Busy Everywhere) response for an initial registration, the UE may attempt to perform initial registration again. 

When the timer F expires at the UE, the UE may: 

a) select a different P-CSCF address from the list of P-CSCF addresses discovered during the procedures described 
in subclause 9.2.1; 

b) if no response has been received when attempting to contact all P-CSCFs known by the UE, the UE may get a 
new set of P-CSCF-addresses as described in subclause 9.2.1; and 

c) perform the procedures for initial registration as described in subclause 5. 1 . 1 .2. 

NOTE 6: It is an implementation option whether these actions are also triggered by other means than expiration of 
timer F, e.g. based on ICMP messages. 

After a maximum of 5 consecutive unsuccessful initial registration attempts, the UE shall not automatically attempt any 
further initial registration via the same network and the same P-CSCF, for an implementation dependant time of at least: 

a) the amount of time indicated in the Retry- After header of the 4xx, 5xx, or 6xx response received in response to 
the most recent registration request, if that header was present; or 

b) 30 minutes, if the header was not present and the initial registration was automatically performed as a 
consequence of a failed reregistration; or 

c) 5 minutes, if the header was not present and the initial registration was not performed as a consequence of a 
failed reregistration. 

These limits do not apply if the UE is power cycled. 

5.1 .1 .3 Initial subscription to the registration-state event package 

Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public 
user identity registered at the user's registrar (S-CSCF) as described in RFC 3680 [43]. 

The UE shall use the default public user identiy for subscription to the registration-state event package, if the public 
user identity that was used for initial registration is a barred public user identity. The UE may use either the default 
public user identity or the public user identity used for initial registration for the subscription to the registration-state 
event package, if the initial public user identity that was used for initial registration is not barred. 

On sending a SUBSCRIBE request, the UE shall populate the header fields as follows: 

a) a Request URI set to the resource to which the UE wants to be subscribed to, i.e. to a SIP URI that contains the 
public user identity used for subscription; 

b) a From header set to a SIP URI that contains the public user identity used for subscription; 

c) a To header set to a SIP URI that contains the public user identity used for subscription; 
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d) an Event header set to the "reg" event package; 

e) an Expires header set to 600 000 seconds as the value desired for the duration of the subscription 

f) if available to the UE (as defined in the access technology specific annexes for each access technology), a P- 
Access-Network-Info header set as specified for the access network technology (see subclause 7.2A.4); and 

g) a Contact header set to contain the same IP address or FQDN, and with the protected server port value as in the 
initial registration. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 

If continued subscription is required, the UE shall automatically refresh the subscription by the reg event package, for a 
previously registered public user identity, either 600 seconds before the expiration time if the initial subscription was 
for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or 
less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall still consider the 
original subscription valid for the duration of the most recently known "Expires" value according to RFC 3265 [28]. 
Otherwise, the UE shall consider the subscription invalid and start a new initial subscription according to 
RFC 3265 [28]. 

5.1 .1 .4 User-initiated reregistration and registration of an additional public user 

identity 

The UE can perform the reregistration of a previously registered public user identity with its contact address at any time 
time after the initial registration has been completed. The UE shall perform the reregistration over the existing set of 
security associations that is associated with the related contact address. 

The UE can perform registration of additional public user identities at any time after the initial registration has been 
completed. The UE shall perform the registration of additional public user identities over the existing set of security 
associations that is associated with the related contact address. 

Unless either the user or the application within the UE has determined that a continued registration is not required the 
UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the 
previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration 
was for 1200 seconds or less, or when the UE intends to update its capabilities according to RFC 3840 [62]. 

The UE shall protect the REGISTER request using a security association, see 3GPP TS 33.203 [19], established as a 
result of an earlier registration, if one is available. 

The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the 
Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A. 

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as 
follows: 

a) an Authorization header, with: 

the username directive set to the value of the private user identity; 

the realm directive, set to the the value as received in the realm directive in the WWW Authenticate header; 

the uri directive, set to the SIP URI of the domain name of the home network; 

the nonce directive, set to last received nonce value; and 

the response directive, set to the last calculated response value; 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URI that contains the public user identity to be registered; 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or 
FQDN and protected server port value bound to the security association, and containing the instance ID of the 
UE in the +sip.instance parameter, if the UE supports GRUU; 
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e) a Via header set to include the IP address or FQDN of the UE in the sent-by field and for the UDP the protected 
server port value bound to the security association, while for the TCP, the response is received on the TCP 
connection on which the request was sent; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
associations. For details on the selection of the protected port value see 3GPP TS 33.203 [19]. 

f) an Expires header, or an expires parameter within the Contact header, set to 600 000 seconds as the value desired 
for the duration of the registration; 

NOTE 3: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) a Security-Client header field, set to specify the security mechanism it supports, the IPsec layer algorithms for 
security and confidentiality protection it supports and the new parameter values needed for the setup of two new 
pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; 

i) a Security- Verify header that contains the content of the Security-Server header received in the 401 
(Unauthorized) response of the last successful authentication; 

j) the Supported header containing the option tag "path", and if GRUU is supported, the option tag "gruu"; and 

k) if available to the UE (as defined in the access technology specific annexes for each access technology), a P- 
Access-Network-Info header set as specified for the access network technology (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the new expiration time of the registration for this public user identity found in the To header value; 

b) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs and standalone transactions; 

NOTE 4: The UE can utilize additional URIs contained in the P-Associated-URI header, e.g. for application 
purposes. 

c) set the security association lifetime to the longest of either the previously existing security association lifetime, 
or the lifetime of the just completed registration plus 30 seconds; and 

NOTE 5: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49]. 

d) find the Contact header within the response that matches the one included in the REGISTER request. If this 
contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, and the UE supports GRUU, then store the 
value of those parameters as the GRUUs for the UE in association with the public user identity that was 
registered. 

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in 
subclause 5.1.1.5.1. 

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall: 

send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) 
response for a reregistration, the UE shall perform the procedures for initial registration as described in 

subclause 5.1.1.2. 

On receiving a 305 (Use Proxy) response to the REGISTER request, the UE shall: 
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a) release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2; 

b) initiate a new P-CSCF discovery procedure as described in subclause 9.2.1; 

c) select a P-CSCF address, which is different from the previously used address, from the address list; and 

d) perform the procedures for initial registration as described in subclause 5.1.1.2. 
When the timer F expires at the UE, the UE shall: 

1) stop processing of all ongoing dialogs and transactions and silently discard them locally; and 

2) after releasing all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2, 
the UE may: 

a) select a different P-CSCF address from the list of P-CSCF addresses discovered during the procedures 
described in subclause 9.2.1; 

b) if no response has been received when attempting to contact all P-CSCFs known by the UE, the UE may get 
a new set of P-CSCF-addresses as described in subclause 9.2.1; and 

c) perform the procedures for initial registration as described in subclause 5. 1 . 1 .2. 

NOTE 6: It is an implementation option whether these actions are also triggered by other means than expiration of 
timer F, e.g. based on ICMP messages. 

5.1.1.5 Authentication 

5.1.1.5.1 General 

Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations, 
deregistrations or registrations of additional public user identities. When the network requires authentication or re- 
authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request. 

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall: 

1) extract the RAND and AUTN parameters; 

2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 [19] i.e. the locally 
calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN 
parameter derived from the AUTN part of the challenge must be within the correct range; and 

3) check the existence of the Security-Server header as described in RFC 3329 [48]. If the header is not present or it 
does not contain the parameters required for the setup of the set of security associations (see annex H of 

3GPP TS 33.203 [19]), the UE shall abandon the authentication procedure and send a new REGISTER request 
with a new Call-ID. 

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall: 

1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203 [19]; 

2) set up a temporary set of security associations based on the static list and parameters it received in the 401 
(Unauthorized) response and its capabilities sent in the Security-Client header in the REGISTER request. The 
UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned 
by the P-CSCF and supported by the UE and using IK and CK (only if encryption enabled) as the shared key. 
The UE shall use the parameters received in the Security-Server header to setup the temporary set of security 
associations. The UE shall set a temporary SIP level lifetime for the temporary set of security associations to the 
value of reg-await-auth timer; and 

3) send another REGISTER request using the temporary set of security associations to protect the message. The 
header fields are populated as defined for the initial request, with the addition that the UE shall include an 
Authorization header containing realm directive set to the value as received in the realm directive in the WWW 
Authenticate header, the private user identity and the authentication challenge response calculated by the UE 
using RES and other parameters, as described in RFC 3310 [49]. The UE shall also insert the Security-Client 
header that is identical to the Security-Client header that was included in the previous REGISTER request (i.e. 
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the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also 
insert the Security- Verify header into the request, by mirroring in it the content of the Security-Server header 
received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the security association protected 
REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 
401 (Unauthorized) response which carried the challenge. 

On receiving the 200 (OK) response for the security association protected REGISTER request, the UE shall: 

change the temporary set of security associations to a newly established set of security associations, i.e. set its 
SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or 
the Ufetime of the just completed registration plus 30 seconds;and 

use the newly established set of security associations for further messages sent towards the P-CSCF as 
appropriate. 

NOTE 1 : In this case, the UE will send requests towards the P-CSCF over the newly established set of security 
associations. Responses towards the P-CSCF that are sent via UDP will be sent over the newly 
established set of security associations. Responses towards the P-CSCF that are sent via TCP will be sent 
over the same set of security associations that the related request was received on. 

When the first request or response protected with the newly established set of security associations is received from the 
P-CSCF, the UE shall delete the old set of security associations and related keys it may have with the P-CSCF after all 
SIP transactions that use the old set of security associations are completed. 

Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security 
associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The 
UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security 
associations. The UE should send an unprotected REGISTER message according to the procedure specified in 
subclause 5.1.1.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF. 

In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in 

subclause 5.1.1.5.3. 

5.1.1.5.2 Network-initiated re-authentication 

At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as described 
in subclause 5.1.1.3). If: 

the state attribute in any of the <registration> elements is set to "active"; 

the value of the <uri> sub-element inside the <contact> sub-element is set to the Contact address that the UE 
registered; and 

the event attribute of that <contact> sub-element(s) is set to "shortened"; 

the UE shall: 

1) use the expiry attribute within the <contact> sub-element that the UE registered to adjust the expiration time for 
that public user identity; and 

2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure described in 
subclause 5.4.1.6) by initiating a reregistration as described in subclause 5.1.1.4, if required. 

NOTE: When authenticating a given private user identity, the S-CSCF will only shorten the expiry time within 
the <contact> sub-element that the UE registered using its private user identity. The <contact> elements 
for the same public user identitity, if registered by another UE using different private user identities 
remain unchanged. The UE will not initiate a reregistration procedure, if none of its <contact> sub- 
elements was modified. 

5.1 .1 .5.3 Abnormal cases 

If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further 
REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows: 
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in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall 
contain no AUTS directive and an empty response directive, i.e. no authentication challenge response; 

in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the 
AUTS directive (see 3GPP TS 33.102 [18]). 

NOTE: In the case of the SQN being out of range, a response directive can be included by the UE, based on the 
procedures described in RFC 3310 [49]. 

Whenever the UE detects any of the above cases, the UE shall: 

send the REGISTER request using an existing set of security associations, if available (see 
3GPPTS 33.203 [19]); 

populate a new Security-Client header within the REGISTER request, set to specify the security mechanism it 
supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the parameters 
needed for the new security association setup; and 

not create a temporary set of security associations. 

A UE shall only respond to two consecutive invalid challenges and shall not automatically attempt authentication after 
two consecutive failed attempts to authenticate. The UE may attempt to register with the network again after an 
implementation specific time. 

5.1 .1 .5A Change of Ipv6 address due to privacy 

Stateless address autoconfiguration as described in RFC 2462 [20E] defines how an IPv6 prefix and an interface 
identifier is used by the UE to construct a complete IPv6 address. 

If the UE receives an IPv6 prefix, the UE may change the interface identity of the IPv6 address as described in 
RFC 3041 [25A] due to privacy but this will result in service discontinuity for IMS services. 

NOTE: The procedure described below will terminate all established dialogs and transactions and temporarily 

disconnect the UE from the IM CN subsystem until the new registration is performed. Due to this, the UE 
is recommended to provide a limited use of the procedure to ensure a maximum degree of continuous 
service to the end user. 

In order to change the IPv6 address due to privacy, the UE shall: 

1) terminate all ongoing dialogs (e.g., sessions) and transactions (e.g., subscription to the reg event); 

2) deregister all registered public user identities as described in subsclause 5 . 1 . 1 .4; 

3) construct a new IPv6 address according to the procedures specified in RFC 3041 [25 A]; 

4) register the public user identities that were deregistered in step 2 above, as follows: 

a) by performing an initial registration as described in subsclause 5. 1 . 1 .2; and 

b) by performing a subscription to the reg event package as described in subsclause 5.1.1.3; and 

5) subscribe to other event packages it was subscribed to before the change of IPv6 address procedure started. 

5.1 .1 .6 User-initiated deregistration 

The UE can deregister a public user identity that it has previously registered with its contact address at any time. 

The UE shall protect the REGISTER request using a security association, see 3GPP TS 33.203 [19], established as a 
result of an earlier registration, if one is available. 

The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the 
Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A. 

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs related to the public user 
identity that is going to be deregistered or to one of the implicitly registered public user identities. However: 
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if the dialog that was established by the UE subscribing to the reg event package used the public user identity 
that is going to be deregistered; and 

this dialog is the only remaining dialog used for subscription to reg event package; 

then the UE shall not release this dialog. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) an Authorization header, with: 

the username directive, set to the value of the private user identity; 

the realm directive, set to the value as received in the realm directive in the WWW- Authenticate header; 

the uri directive, set to the SIP URI of the domain name of the home network; 

the nonce directive, set to last received nonce value; and 

the response directive, set to the last calculated response value; 

b) a From header set to the SIP URI that contains the public user identity to be deregistered; 

c) a To header set to the SIP URI that contains the public user identity to be deregistered; 

d) a Contact header set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP 
address of the UE or FQDN and the protected server port value bound to the security association, and containing 
the Instance ID of the UE in the +sip. instance parameter, if the UE supports GRUU; 

e) a Via header set to include the IP address or FQDN of the UE in the sent-by field and the protected server port 
value bound to the security association; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

f) an Expires header, or the expires parameter of the Contact header, set to the value of zero, appropriate to the 
deregistration requirements of the user; 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) a Security-Client header field, set to specify the security mechanism it supports, the IPsec layer algorithms for 
integrity and confidentiality protection it supports and the new parameter values needed for the setup of two new 
pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; 

i) a Security-Verify header that contains the content of the Security-Server header received in the 401 
(Unauthorized) response of the last successful authentication; and 

j) if available to the UE (as defined in the access technology specific annexes for each access technology), a P- 
Access-Network-Info header set as specified for the access network technology (see subclause 7.2A.4). 

When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in 
subclause 5.1.1.5.1. 

On receiving the 200 (OK) response to the REGISTER request, the UE shall remove all registration details relating to 
this public user identity. 

If there are no more public user identities registered, the UE shall delete the security associations and related keys it 
may have towards the IM CN subsystem. 

If all public user identities are deregistered and the security association is removed, then the UE shall consider 
subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires 
header containing a value of zero). 
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NOTE 2: When the UE has received the 200 (OK) response for the REGISTER request of the only public user 
identity currently registered with its associated set of implicitly registered public user identities (i.e. no 
other is registered), the UE removes the security association established between the P-CSCF and the UE. 
Therefore further SIP signalling (e.g. the NOTIFY request containing the deregistration event) will not 
reach the UE. 

5.1 .1 .7 Network-initiated deregistration 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as 
described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE with: 

the state attribute set to "terminated" and the event attribute within the <contact> element belonging to this UE 
set to "rejected" or "deactivated"; or 

the state attribute set to "active" and within the <contact> element belonging to this UE, the state attribute set to 
"terminated" and the associated event attribute set to "rejected" or "deactivated"; 

the UE shall remove all registration details relating to these public user identities. In case of a "deactivated" event 
attribute, the UE shall start the initial registration procedure as described in subclause 5.1.1.2. In case of a "rejected" 
event attribute, the UE shall release all dialogs related to those public user identities. 

Upon receipt of a NOTIFY request, the UE shall delete the security associations towards the P-CSCF either: 

if all <registration> element(s) have their state attribute set to "terminated" (i.e. all public user identities are 
deregistered) and the Subscription-State header contains the value of "terminated"; or 

if each <registration> element that was registered by this UE has either the state attribute set to "terminated", or 
the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to 
"terminated". 

The UE shall delete these security associations towards the P-CSCF after the server transaction (as defined in RFC 
3261 [26]) pertaining to the received NOTIFY request terminates. 

NOTE 1 : Deleting a security association is an internal procedure of the UE and does not involve any SIP 
procedures. 

NOTE 2: If all the public user identities or contact addresses registered by this UE are deregistered and the security 
association is removed, the UE considers the subscription to the reg event package terminated since the 
NOTIFY request was received with Subscription-State header containing the value of "terminated"). 

5.1 .2 Subscription and notification 

5.1 .2.1 Notification about multiple registered public user identities 

Upon receipt of a 2xx response to the SUBSCRIBE request the UE shall maintain the generated dialog (identified by 
the values of the Call-ID, To and From headers). 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package the 
UE shall perform the following actions: 

if a state attribute "active", i.e. registered is received for one or more public user identities, the UE shall store the 
indicated public user identities as registered; 

if a state attribute "active" is received, and the UE supports GRUU, then for each public user identity indicated in 
the notification that contains a <pub-gruu> element or a <temp-gruu> element or both (as defined in draft-ietf- 
sipping-gruu-reg-event [94]) then the UE shall store the value of those elements in association with the public 
user identity; 

if a state attribute "terminated", i.e. deregistered is received for one or more public user identities, the UE shall 
store the indicated public user identities as deregistered and shall remove any associated GRUUs. 
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NOTE: There may be public user identities which are automatically registered within the registrar (S-CSCF) of 
the user upon registration of one public user identity or when S-CSCF receives a Push-Profile-Request 
(PPR) from the HSS (as described in 3GPP TS 29.228 [14]) changing the status of a public user identity 
associated with a registered implicit set from barred to non-barred. Usually these automatically or 
implicitly registered public user identities belong to the same service profile of the user and they might 
not be available within the UE. The implicitly registered public user identities may also belong to 
different service profiles. The here-described procedures provide a different mechanism (to the 200 (OK) 
response to the REGISTER request) to inform the UE about these automatically registered public user 
identities. 

5.1 .2.2 General SUBSCRIBE requirements 

If the UA receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry- After 
header, then the UE shall not automatically reattempt the request until after the period indicated by the Retry- After 
header contents. 

5.1 .2A Generic procedures applicable to all methods excluding the 
REGISTER method 

5.1.2A.1 UE-originating case 

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method. 

When the UE sends any request, the UE shall: 

include the protected server port in the Via header entry relating to the UE. 

The UE shall discard any SIP response that is not protected by the security association and is received from the P-CSCF 
outside of the registration and authentication procedures. The requirements on the UE within the registration and 
authentication procedures are defined in subclause 5.1.1. 

In accordance with RFC 3325 [34] the UE may insert a P-Preferred-Identity header in any initial request for a dialog or 
request for a standalone transaction as a hint for creation of an asserted identity (contained in the P-Asserted-Identity 
header) within the IM CN subsystem. 

NOTE 1: Since the S-CSCF uses the P-Asserted-Identity header when checking whether the UE originating request 
matches the initial filter criteria, the P-Preferred-Identity header inserted by the UE determines which 
services and applications are invoked. 

The UE may include any of the following in the P-Preferred-Identity header: 

a public user identity which has been registered by the user; 

a public user identity returned in a registration-state event package of a NOTIFY request as a result of an implict 
registration that was not subsequently deregistered or has expired; or 

any other public user identity which the user has assumed by mechanisms outside the scope of this specification 
to have a current registration. 

NOTE 2: The temporary public user identity specified in subclause 5.1.1.1 is not a public user identity suitable for 
use in the P-Preferred-Identity header. 

NOTE 3: Procedures in the network require international public telecommunication numbers when telephone 
numbers are used in P-Preferred-Identity header. 

NOTE 4: A number of headers can reveal information about the identity of the user. Where privacy is required, 
implementers should also give consideration to other headers that can reveal identity information. 
RFC 3323 [33] subclause 4.1 gives considerations relating to a number of headers. 

Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the UE shall set the 
From header to "Anonymous" as specified in RFC 3261 [26]. 
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NOTE 5: The contents of the From header should not be rehed upon to be modified by the network based on any 
privacy specified by the user either within the UE indication of privacy or by network subscription or 
network poHcy. Therefore the user should include the value "Anonymous" whenever privacy is explicitly 
required. As the user may well have privacy requirements, terminal manufacturers should not 
automatically derive and include values in this header from the public user identity or other values stored 
in or derived from the UICC. Where the user has not expressed a preference in the configuration of the 
terminal implementation, the implementation should assume that privacy is required. Users that require to 
identify themselves, and are making calls to SIP destinations beyond the IM CN subsystem, where the 
destination does not implement RFC 3325 [34], will need to include a value in the From header other than 
Anonymous. 

The UE shall determine the public user identity to be used for this request as follows: 

1) if a P -Preferred-Identity was included, then use that as the public user identity for this request; or 

2) if no P-Preferred-Identity was included, then use the default public user identity for the security association as 
the public user identity for this request; 

If this is a request for a new dialog, and the request includes a Contact header, then the UE should populate the Contact 
header as follows: 

1) if a public GRUU value (pub-gruu) has been saved associated with the public user identity to be used for this 
request, and the UE does not indicate privacy of the P-Asserted-Identity, then insert the public GRUU (pub- 
gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93]; and 

2) if a temporary GRUU value (temp-gruu) has been saved associated with the public user identity to be used for 
this request, and the UE does indicate privacy of the P-Asserted-Identity, then insert the temporary GRUU 
(temp-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93]. 

If this is a request within an existing dialog, and the request includes a Contact header, and the Contact address 
previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact 
header as specified in draft-ietf-sip-gruu [93]. 

If the UE did not insert a GRUU in the Contact header, then the UE shall include the protected server port in the address 
in the Contact header. 

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with 
RFC 3323 [33], and the additional requirements contained within RFC 3325 [34]. 

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall 
insert a P- Access-Network-Info header into any request for a dialog, any subsequent request (except ACK requests and 
CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a standalone method 
(see subclause 7.2A.4). 

NOTE 6: During the dialog, the points of attachment to the IP-CAN of the UE may change (e.g. UE connects to 
different cells). The UE will populate the P- Access-Network-Info header in any request or response 
within a dialog with the current point of attachment to the IP -CAN (e.g. the current cell information). 

The UE shall build a proper preloaded Route header value for all new dialogs and standalone transactions. The UE shall 
build a list of Route header values made out of, in this order, the P-CSCF URI (containing the IP address or the FQDN 
learnt through the P-CSCF discovery procedures, and the protected server port learnt during the registration procedure), 
and the values received in the Service-Route header saved from the 200 (OK) response to the last registration or re- 
registration. 

The UE may indicate that proxies should not fork the request by including a "no-fork" directive within the Request- 
Disposition header in the request as described in RFC 3841 [56B]. 

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F 
expired, as described in subclause 5.1.1.4. 

NOTE 7: It is an implementation option whether these actions are also triggered by other means. 

The UE may use non-international formats of E. 164 addresses, called local service numbers, in the Request-URL 

NOTE 8: The way how the UE defines the default network for local service numbers is implementation specific. 
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NOTE 9: Home operator"s local policy can define a prefix string(s) to enable subscribers to differentiate dialing a 
geo-local service number and/or home-local service number. 

Editor's note: The current solution for local service number handling proposes to insert all dialled digits including 
prefix strings into the "local-number-digits" part of the tel URI. The "phone-context" parameter will 
always include a domain name belonging to an IMS operator where the local service number is translated 
to a globally routable SIP URI or an international tel URI. It is FFS whether a solution based on draft- 
rosen-iptel-dialstring will be used. Note that if the dialled string include special characters (e.g. pause) 
that cannot be inserted into the "local-number-digits" part of the tel URI, then either the UE have to 
preprocess the dialled string (e.g. include part of the dialled string into the "extension" parameter of the 
tel URI), or the solution proposed in draft-rosen-iptel-dialstring will be used and the dialled string is 
processed in the network. The handling of these special characters is not local service number specific. 

When the UE uses local service number, the UE shall: 

1) when using home-local service number include in the "phone-context" parameter the home domain name in 
accordance with RFC 3966 [22]; and 

2) when using geo-local service number: 

if access technology information available to the UE (i.e., the UE can insert P-Access-Network-Info header 
into the request), include the access technology information in the "phone-context" parameter according to 
RFC 3966 [22] as defined in subclause 7.2A.10; and 

if access technology information is not available to the UE (i.e., the UE cannot insert P-Access-Network-Info 
header into the request), include in the "phone-context" parameter the home domain name according to 
RFC 3966 [22]. 

NOTE 10:The "phone-context" parameter value can be entered by the subscriber, or can be inserted by the UE, 
based on implementation. 

5.1 .2A.2 UE-terminating case 

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method. 

The UE shall discard any SIP request that is not protected by the security association and is received from the P-CSCF 
outside of the registration and authentication procedures. The requirements on the UE within the registration and 
authentication procedures are defined in subclause 5.1.1. 

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with 
RFC 3323 [33], and the additional requirements contained within RFC 3325 [34]. 

NOTE 1 : In the UE-terminating case, this version of the document makes no provision for the UE to provide an P- 
Preferred-Identity in the form of a hint. 

NOTE 2: A number of headers can reveal information about the identity of the user. Where, privacy is required, 
implementers should also give consideration to other headers that can reveal identity information. 
RFC 3323 [33] subclause 4.1 gives considerations relating to a number of headers. 

If the response includes a Contact header, and the response is sent within an existing dialog, and the Contact address 
previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact 
header as specified in draft- ietf-sip-gruu [93]. 

If the response includes a Contact header, and the response is not sent within an existing dialog, then the UE should 
populate the Contact header as follows: 

1) if a public GRUU value (pub-gruu) has been saved associated with the public user identity from the P-Called- 
Party-ID header, and the UE does not indicate privacy of the P-Asserted-Identity, then insert the public GRUU 
(pub-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93]; and 

2) if a temporary GRUU value (temp-gruu) has been saved associated with the public user identity from the P- 
Called-Party-ID header, and the UE does indicate privacy of the P-Asserted-Identity, then the UE should insert 
the temporary GRUU (temp-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93]. 
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If the UE did not insert a GRUU in the Contact header, then the UE shall include the protected server port in the address 
in the Contact header. 

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall 
insert a P- Access-Network-Info header into any response to a request for a dialog, any subsequent request (except 
CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone method 
(see subclause 7.2A.4). 

5.1 .3 Call initiation - UE-originating case 
5.1.3.1 InitiallNVITE request 

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the 
precondition mechanism" and is defined in RFC 3312 [30] as updated by RFC 4032 [64]. 

The preconditions mechanism should be supported by the originating UE. 

The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource 
reservation. 

NOTE 1 : The originating UE can decide if local resource reservation is required based on e.g. application 
requirements, current access network capabilities, local configuration, etc. 

In order to allow the peer entity to reserve its required resources, an originating UE supporting the precondition 
mechanism should make use of the precondition mechanism, even if it does not require local resource reservation. 

Upon generating an initial INVITE request using the precondition mechanism, the UE shall: 

indicate the support for reliable provisional responses and specify it using the Supported header mechanism; and 

indicate the support for the preconditions mechanism and specify it using the Supported header mechanism. 

Upon generating an initial INVITE request using the precondition mechanism, the UE should not indicate the 
requirement for the precondition mechanism by using the Require header mechanism. 

NOTE 2: If an UE chooses to require the precondition mechanism, i.e. if it indicates the "precondition" option tag 
within the Require header, the interworking with a remote UE, that does not support the precondition 
mechanism, is not described in this specification. 

NOTE 3: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26]. The UE can 
accept or reject any of the forked responses, for example, if the UE is capable of supporting a limited 
number of simultaneous transactions or early dialogs. 

Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see 
subclause 6.1.2) within the next SIP request. 

NOTE 4: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a 
PRACK request or an UPDATE request. In case of the precondition mechanism not being supported on 
one or both sides, alternatively a relNVITE request can be used for this confirmation, in case the 
terminating UE does not support the PRACK request (as described in RFC 3262 [27]) and does not 
support the UPDATE request (as described in RFC 33 11 [29]). 

When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The UE shall 
not progress any remaining early dialogues to established dialogs. Therefore, upon the reception of a subsequent final 
200 (OK) response for an INVITE request (e.g., due to forking), the UE shall: 

1) acknowledge the response with an ACK request; and 

2) send a BYE request to this dialog in order to terminate it. 

Upon receiving a 488 (Not Acceptable Here) response to an initial INVITE request, the originating UE should send a 
new INVITE request containing SDP according to the procedures defined in subclause 6.1. 
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NOTE 5: An example of where a new request would not be sent is where knowledge exists within the UE, or 

interaction occurs with the user, such that it is known that the resulting SDP would describe a session that 
did not meet the user requirements. 

Upon receiving a 421 (Extension Required) response to an initial INVITE request in which the precondition mechanism 
was not used, including the "precondition" option tag in the Require header, the originating UE shall send a new 
INVITE request using the precondition mechanism, if the originating UE supports the precondition mechanism. 

Upon receiving a 503 (Service Unavailable) response to an initial INVITE request containing a Retry- After header, then 
the originating UE shall not automatically reattempt the request until after the period indicated by the Retry- After 
header contents. 

5.1 .4 Call initiation - UE-terminating case 
5.1 .4.1 Initial INVITE request 

The preconditions mechanism should be supported by the terminating UE. 

The handling of incoming initial INVITE requests at the terminating UE is mainly dependent on the following 
conditions: 

the specific service requirements for "integration of resource management and SIP" extension (hereafter in this 
subclause known as the precondition mechanism and defined in RFC 3312 [30] as updated by RFC 4032 [64], 
and with the request for such a mechanism known as a precondition); and 

the UEs configuration for the case when the specific service does not require the precondition mechanism. 

If an initial INVITE request is received the terminating UE shall check whether the terminating UE requires local 
resource reservation. 

NOTE 1 : The terminating UE can decide if local resource reservation is required based on e.g. application 
requirements, current access network capabilities, local configuration, etc. 

If local resource reservation is required at the terminating UE and the terminating UE supports the precondition 
mechanism, and: 

a) the received INVITE request includes the "precondition" option-tag in the Supported header or Require header, 
the terminating UE shall make use of the precondition mechanism and shall indicate a Require header with the 
"precondition" option-tag in any response or subsequent request it sends towards to the originating UE; or 

b) the received INVITE request does not include the "precondition" option-tag in the Supported header or Require 
header, the terminating UE shall not make use of the precondition mechanism. 

If local resource reservation is not required by the terminating UE andthe terminating UE supports the precondition 
mechanism and: 

a) the received INVITE request includes the "precondition" option-tag in the Supported header and: 

the required resources at the originating UE are not reserved, the terminating UE shall use the precondition 
mechanism; or 

the required local resources at the originating UE and the terminating UE are available, the terminating UE 
may use the precondition mechanism; 

b) the received INVITE request does not include the "precondition" option-tag in the Supported header or Require 
header, the terminating UE shall not make use of the precondition mechanism; or 

c) the received INVITE request includes the "precondition" option-tag in the Require header, the terminating UE 
shall use the precondition mechanism. 

NOTE 2: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26]. 

NOTE 3: If the terminating UE does not support the precondition mechanism it will apply regular SIP session 
initiation procedures. 
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If the terminating UE requires a reliable alerting indication at the originating side, it shall send the 180 (Ringing) 
response reliably. If the received INVITE indicated support for reliable provisionable responses, but did not require 
their use, the terminating UE shall send provisional responses reliably only if the provisional response carries SDP or 
for other application related purposes that requires its reliable transport. 

5.1.5 Call release 

Void. 

5.1.6 Emergency service 

5.1.6.1 General 

A CS and IM CN subsystem capable UE shall follow the conventions and rules specified in 3GPP TS 22.101 [lA] and 
3GPP TS 23.167 [8D] to select the domain for the emergency call attempt. If the CS domain is selected, the UE shall 
attempt an emergency call setup according to the procedures described in 3GPP TS 24.008 [8]. 

If the IM CN subsystem is selected and the UE is currently attached to its home operators network and the UE is 
currently registered, the UE shall attempt an emergency call as described in subclause 5.1.6.8.4. 

If the IM CN subsystem is selected and the UE is currently attached to its home operators network and the UE is not 
currently registered, the UE shall: 

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and 

2) attempt an emergency call as described in subclause 5. 1.6.8.3. 

If the IM CN subsystem is selected and the UE is attached to a different network than its home operatos network and 
the assigned P-CSCF is from its home operator"s network, the UE shall: 

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and 

2) attempt an emergency call as described in subclause 5. 1.6.8.3. 

Editor's Note: The mechanism how the UE finds out whether it is attached to the home operators network or to a 
visited network are access specific and have to be defined in the Annexes. A reference is needed here to 
the related Annexes. 

The IP-CAN can, dependant on the IP-CAN capabilities, provide local emergency numbers to the UE which has that 
capability, in order for the UE to recognize these numbers as emergency call. 

5.1 .6.2 Initial emergency registration 

Editor's note: It needs to be stated that the UE must be capable to handle the emergency registration completely 

independent of a possible already existing registration. The already existing (non-emergency) registration 
shall not be influenced by the parallel emergency registration. 

When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause 5.1.1.2 
with the following additions: 

the UE shall populate the To and From header in the REGISTER request with the emergency public user identity 
as specified in 3GPP TS 23.003 [3]. 

Editor's note: More additions needed, stating that UE can register without credentials in the case that regulation 
allows & UE has no credentials or no credentials that can be handled at the S-CSCF. 

Editor's note: In the case when no UICC is available, it needs to be defined where is the emergency public user 

identity and maybe the private user identity are taken from. Also it needs to be clarified where the UE (for 
emergency registration) gets the home network domain from. Will this only be reflected in 23.003? For 
this case it also needs to be indicated whether an Authorization header will be included or not. 

Editor's note: The format of the emergency public user identity needs to still be defined. 
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5.1 .6.2A New initial emergency registration 

The UE shall perform a new initial emergency registration, as specified in subclause 5.1.6.2, if the UE determines that: 

it has previously performed an emergency registration which has not yet expired; and 

it has obtained an IP address from the serving IP-CAN, as specified in subclause 9.2.1, different than the IP 
address used for the emergency registration. 

5.1 .6.3 Initial subscription to the registration-state event package 

The UE shall not subscribe to the reg event package for any emergency public user identity. 

5.1 .6.4 User-initiated emergency reregistration 

With one exception the UE shall not perform user-initiated emergency reregistration. If the emergency registratation is 
expected to expire during an ongoing dialog or if outstanding transactions exist, the UE shall perform user-initiated 
emergency reregistration as specified in subclause 5.1.1.4. The UE shall perform the emergency reregistration before 
the the ongoing emergency registration expires. 

5.1.6.5 Authentication 

When a UE performs authentication a UE shall perform the procedures as specified in subclause 5.1.1.5. 

Editor's Note; Is it allowed that if the UE has a UICC (and related credentials), that the S-CSCF does not challenge 
the UE? This might be applied to speed up the emergency registration procedure. 

5.1 .6.6 User-initiated emergency deregistration 

The UE shall not perform user-initiated deregistration of any registered emergency public user identity. 
NOTE: The UE will be deregistered when the emergency registration expires. 

5.1 .6.7 Network-initiated emergency deregistration 

An emregency registrition will not be deregistered by the network (see subclause 5.4.8.4). 

5.1 .6.8 Emergency session setup 

5.1.6.8.1 General 

In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing a XML 
body that includes an <alternative service> element with the <type> child element set to "emergency", the UE shall 
automatically send an ACK request to the P-CSCF as per normal SIP procedures and terminate the session. 

NOTE 1 : The UE can attempt an emergency call setup according to the procedures described in 
3GPPTS 24.008 [8]. 

NOTE 2: Emergency numbers which the UE does not detect, will be treated as a normal call. 

5.1 .6.8.2 Emergency session set-up in case of no registration 

The UE shall apply the procedures as specified in subclause 5.1.3 with the following additions: 

1) the UE shall set the From header field of the INVITE request to "Anonymous" as specified in RFC 3261 [26]; 

2) the UE shall include a Request-URI in the INVITE request that contains an emergency service URN, i.e. with 
"sos" service type as specified in draft ietf-ecrit-service-urn [69]. An additional sub-service type can be added if 
information on the type of emergency service is known; 
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NOTE 1 : Other specifications make provision for emergency service identifiers, that are not specifically the 

emergency service URN, to be recognised in the UE. Emergency service identifiers which the UE does 
not detect will be treated as a normal call by the UE. 

3) if available to the UE (as defined in the access technology specific annexes for each access technology), the UE 
shall include in the P-Access-Network-Info header in any request for a dialog, any subsequent request (except 
ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any request. 
The UE shall populate the P- Access-Network-Info header with the current point of attachment to the IP-CAN as 
specified for the access network technology (see subclause 7.2A.4). The P-Access-Network-Info header contains 
the location identifier such as the cell id, the line id or the identity of the I-WLAN access node, which is relevant 
for routing the IMS emergency call; 

4) the UE shall populate the P-Preferred-Identity header in the INVITE request with an equipment identifier as a 
SIP URI. The special details of the equipment identifier to use depends on the IP-CAN; and 

5) if the UE has its location information available, it shall include the location information in the INVITE request in 
the following way: 

if the UE is aware of the URI that points to where the UE's location is stored, include the URI in the 
Geolocation header and set the value of the Supported header to "geolocation" in accordance with draft-ietf- 
sip-location-conveyance [89]; or 

if the geolocation of the UE is available to the UE, include its geolocation as PIDF location object in 
accordance with RFC 4119 [90] and include the location object in a message body with the content type 
application/pidf-Hxml in accordance with draft-ietf-sip-location-conveyance [89]. The Geolocation header is 
set to a Content ID and the value of the Supported header to "geolocation" in accordance with draft-ietf-sip- 
location-conveyance [89]. 

NOTE 2: It is suggested that UE's only use the option of providing a URI when the domain part belongs to the 
current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide 
guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is 
not desirable. 

Editor's Note: The profile tables in annex A to this document needs to be updated with draft-ietf-sip-Iocation- 
conveyance. 

Editor's Note: It is FFS how the UE will indicate if no location is available if the UE does not support draft-ietf-sip- 
location-conveyance [89]. 

NOTE 3: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to 
different cells). The UE will populate the P- Access-Network-Info header in any request or response 
within a dialog with the current point of attachment to the IP -CAN (e.g. the current cell information). 

The UE shall build a proper preloaded Route header value for all new dialogs. The UE shall build a Route header value 
made out of, the P-CSCF URI (containing the IP address or the FQDN learnt through the P-CSCF discovery 
procedures). 

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F 
expired, as described in subclause 5.1.1.4. 

NOTE 4: It is an implementation option whether these actions are also triggered by other means. 

NOTE 5: A number of headers can reveal information about the identity of the user. Where privacy is required, 
implementers should also give consideration to other headers that can reveal identity information. 
RFC 3323 [33] subclause 4.1 gives considerations relating to a number of headers. 

Editor's note: The use of the Priority header with the value "emergency" requires further study. 

5.1 .6.8.3 Emergency session set-up within an emergency registration 

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A, 
5.1.3 and 5.1.4 with the following additions: 
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1) the UE shall include a Request URI in the INVITE request that contains an emergency service URN, i.e. with 
"sos" service type as specified in draft-ietf-ecrit-service-urn [69]. An additional sub-service type can be added if 
information on the type of emergency service is known; 

2) the UE shall insert in the INVITE request, a P-Preferred-Identity header that includes the tel URI associated with 
the emergency public user identity as described in subclause 4.2; 

3) if the UE has its location information available, it shall include it in the INVITE request in the following way: 

if the UE is aware of the URI that points to where the UE's location is stored, include the URI in the 
Geolocation header and set the value of the Supported header to "geolocation" in accordance with draft-ietf- 
sip-location-conveyance [89]; or 

if the geolocation of the UE is available to the UE, include its geolocation as PIDF location object in 
accordance with RFC 4119 [90] and include the location object in a message body with the content type 
application/pidf+xml in accordance with draft-ietf-sip-location-conveyance [89]. The Geolocation header is 
set to a Content ID and the value of the Supported header to "geolocation" in accordance with draft-ietf-sip- 
location-conveyance [89]; and 

NOTE 1 : It is suggested that UE's only use the option of providing a URI when the domain part belongs to the 
current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide 
guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is 
not desirable. 

4) if available to the UE, the P-Access-Network-Info header shall contain a location identifier such as the cell id, 
line id or the identity of the I-WLAN access node, which is relevant for routing the IMS emergency call; 

Editor's Note: It is FFS how the UE will indicate if no location is available if the UE does not support draft-ietf-sip- 
location-conveyance [89]. 

Editor's note: The use of the Priority header with the value "emergency" requires further study. 

NOTE 2: The IMS emergency specification in 3GPP TS 23.167 [4B] describes several methods how the UE can get 
its location information from the access network or from a server. Such methods are not in the scope of 
this specification. 

5.1 .6.8.4 Emergency session setup within a non-emergency registration 

The UE shall apply the procedures as specified in subclauses 5.1.2A, 5.1.3 and 5.1.4 with the following additions: 

1) the UE shall include a Request URI in the INVITE request that contains an emergency service URN, i.e. with 
"sos" service type as specified in draft-ietf-ecrit-service-urn [69]. An additional sub-service type can be added if 
information on the type of emergency service is known; 

2) the UE shall include a P-Preferred-Identity value in the INVITE request with the public user identity or the tel 
URI associated with the public user identity as described in subclause 4.2; and 

3) if the UE has its location information available, it shall include it in the INVITE request in the following way: 

if the UE is aware of the URI that points to where the UE's location is stored, include the URI in the Location 
header and set the value of the Supported header to "location" in accordance with draft-ietf-sip-location- 
conveyance [89]; or 

if the location of the UE is available to the UE, include its location as PIDF location object in accordance 
with RFC 41 19 [90] and include the location object in a message body with the content type applica- 
tion/pidf-Hxml in accordance with draft-ietf-sip-location-conveyance [89]. The Location header is set to a 
Content ID and the value of the Supported header to "location" in accordance with draft-ietf-sip-location- 
conveyance [89]. 

NOTE: It is suggested that UE's only use the option of providing a URI when the domain part belongs to the 
current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide 
guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is 
not desirable. 
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Upon receiving a 380 (Alternative Service) response to the INVITE request, with the 380 (Alternative Service) response 
include a IM CN subsystem XML body, with the type element set to 'emergency' and the action element set to 
'emergency-registration' the the UE shall: 

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and 

2) attempt an emergency call as described in subclause 5. 1.6.8.3. 

Editor's Note: The UE shall indicate if no location is available. How this is indicated is for further study. 

Editor's note: The use of the Priority header with the value "emergency" requires further study. 

Editor's Note: The way how they UE obtain the location information needs to be specified. However, where to insert 
the text still requires further study. 

5.1 .6.9 Emergency session release 

Normal call release procedure shall apply, as specified in the subclause 5.1.5. 

5.1.7 Void 

5.2 Procedures at the P-CSCF 
5.2.1 General 

Subclause 5.2.2 through subclause 5.2.9 define P-CSCF procedures for SIP that do not relate to emergency. All SIP 
requests are first screened according to the procedures of subclause 5.2.10 to see if they do relate to an emergency. 

The P-CSCF shall support the Path and Service-Route headers. 

NOTE 1 : The Path header is only applicable to the REGISTER request and its 200 (OK) response. The Service- 
Route header is only applicable to the 200 (OK) response of REGISTER request. 

When the P-CSCF sends any request or response to the UE, before sending the message the P-CSCF shall: 

remove the P-Charging-Function- Addresses and P-Charging-Vector headers, if present. 

When the P-CSCF receives any request or response from the UE, the P-CSCF shall: 

remove the P-Charging-Function- Addresses and P-Charging- Vector headers, if present. Also, the P-CSCF shall 
ignore any data received in the P-Charging-Function-Addresses and P-Charging- Vector headers; and 

may insert previously saved values into the P-Charging-Function- Addresses and P-Charging-Vector headers 
before forwarding the message. 

NOTE 2: When the P-CSCF is located in the visited network, then it will not receive the P-Charging-Function- 

Addresses header from the S-CSCF, IBCF, or I-CSCF. Instead, the P-CSCF discovers charging function 
addresses by other means not specified in this document. 

When the P-CSCF receives any request or response containing the P-Media- Authorization header, the P-CSCF shall 
remove the header. 

NOTE 3: If service based local policy applies, the P-CSCF will insert the P-Media- Authorization header as 
described in subclauses 5.2.7.2 and 5.2.7.3. 

NOTE 4: The P-CSCF will integrity protect all SIP messages sent to the UE outside of the registration and 

authentication procedures by using a security association. The P-CSCF will discard any SIP message that 
is not protected by using a security association and is received outside of the registration and 
authentication procedures. The integrity and confidentiality protection and checking requirements on the 
P-CSCF within the registration and authentication procedures are defined in subclause 5.2.2. 

With the exception of 305 (Use Proxy) responses, the P-CSCF shall not recurse on 3xx responses. 
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In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT controlled 
by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in annex F. In 
case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT not 
controlled by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in 
annex K if both a reg-id and instance ID parameter are present in the received contact header as described in draft-ieft- 
outbound [92]. 

5.2.2 Registration 

The P-CSCF shall be prepared to receive only the initial REGISTER requests on the SIP default port values as specified 
in RFC 3261 [26]. The P-CSCF shall also be prepared to receive only the initial REGISTER requests on the port 
advertised to the UE during the P-CSCF discovery procedure. 

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall: 

1) insert a Path header in the request including an entry containing: 

- the SIP URI identifying the P-CSCF; 

an indication that requests routed in this direction of the path (i.e. from the S-CSCF towards the P-CSCF) are 
expected to be treated as for the UE-terminating case. This indication may e.g. be in a parameter in the URI, 
a character string in the user part of the URI, or be a port number in the URI; 

2) insert a Require header containing the option tag "path"; 

3) insert a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17] and a 
type 1 orig-ioi parameter. The P-CSCF shall set the type 1 orig-ioi parameter to a value that identifies the 
sending network of the request. The P-CSCF shall not include the type 1 term-ioi parameter; 

4) insert the parameter "integrity-protected" (described in subclause 7.2A.2) with a value "yes" into the 
Authorization header field in case the REGISTER request was either received protected with the security 
association created during an ongoing authentication procedure and includes an authentication challenge 
response (i.e. RES parameter), or it was received on the security association created during the last successful 
authentication procedure and with no authentication challenge response (i.e. no RES parameter), otherwise insert 
the parameter with the value "no"; 

5) in case the REGISTER request was received without protection, then check the existence of the Security-Client 
header. If the header is present, then remove and store it. If the header is not present, then the P-CSCF shall 
return a suitable 4xx response; 

6) in case the REGISTER request was received protected, then the P-CSCF shall: 

a) check the security association which protected the request. If the security association is a temporary one, then 
the request is expected to contain a Security-Verify header in addition to a Security-Client header. If there are 
no such headers, then the P-CSCF shall return a suitable 4xx response. If there are such headers, then the P- 
CSCF shall compare the content of the Security- Verify header with the content of the Security-Server header 
sent earlier and the content of the Security-Client header with the content of the Security-Client header 
received in the challenged REGISTER. If those do not match, then there is a potential man-in-the-middle 
attack. The request should be rejected by sending a suitable 4xx response. If the contents match, the P-CSCF 
shall remove the Security- Verify and the Security-Client header; 

b) if the security association the REGISTER request was received on, is an already established one, then: 

- the P-CSCF shall remove the Security- Verify header if it is present; 

a Security-Client header containing new parameter values is expected. If this header or any required 
parameter is missing, then the P-CSCF shall return a suitable 4xx response; 

- the P-CSCF shall remove and store the Security-Client header before forwarding the request to the S- 
CSCF; and 

c) check if the private user identity conveyed in the Authorization header of the protected REGISTER request is 
the same as the private user identity which was previously challenged or authenticated. If the private user 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 54 ETSI TS 1 24 229 V7.6.0 (2006-1 2) 

identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) 
response; 

7) insert a P-Visited-Network-ID header field, with the value of a pre-provisioned string that identifies the visited 
network at the home network; 

8) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in 
the visited network towards the home network, forward the request to an IBCF in the visited network 

If the selected exit point: 

does not respond to the REGISTER request and its retransmissions by the P-CSCF; or 

sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

the P-CSCF shall select a new exit point and forward the original REGISTER request. 

NOTE 1 : The list of the exit points can be either obtained as specified in RFC 3263 [27 A] or provisioned in the P- 
CSCF. 

If the P-CSCF fails to forward the REGISTER request to any exit point, the P-CSCF shall send back a 504 
(Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [26] unless local policy 
allows omitting the exit point; and 

NOTE 2: If the P-CSCF forwards the request to an IBCF in the visited network, the IBCF can determine the entry 
point of the home network, using the same mechanisms as described in NOTE 1 above. In that case the P- 
CSCF does not need to determine the entry point of the home network. 

9) determine the entry point of the home network and forward the request to that entry point. 
If the selected entry point: 

does not respond to the REGISTER request and its retransmissions by the P-CSCF; or 

sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

the P-CSCF shall select a new entry point and forward the original REGISTER request. 

NOTE 3: The list of the entry points can be either obtained as specified in RFC 3263 [27 A] or provisioned in the 
P-CSCF. 

If the P-CSCF fails to forward the REGISTER request to any entry point, the P-CSCF shall send back a or 504 
(Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [26]. 

When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the P-CSCF shall: 

1) delete any temporary set of security associations established towards the UE; 

2) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the proper private 
user identity and to the temporary set of security associations which will be setup as a result of this challenge. 
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK have been 
removed; 

3) insert a Security-Server header in the response, containing the P-CSCF static security list and the parameters 
needed for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall 
support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the 
IPsec layer algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19] and shall 
announce support for them according to the procedures defined in RFC 3329 [48]; 

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P- 
CSCF for the user identified with the private user identity. For further details see 3GPP TS 33.203 [19] and 
RFC 3329 [48]. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security 
associations to the value of reg-await-auth timer; and 

5) send the 401 (Unauthorized) response to the UE using the security association with which the associated 
REGISTER request was protected, or unprotected in case the REGISTER request was received unprotected. 
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NOTE 4: The challenge in the 401 (Unauthorized) response sent back by the S-CSCF to the UE as a response to the 
REGISTER request is piggybacked by the P-CSCF to insert the Security-Server header field in it. The S- 
CSCF authenticates the UE, while the P-CSCF negotiates and sets up two pairs of security associations 
with the UE during the same registration procedure. For further details see 3GPP TS 33.203 [19]. 

When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shall check the value of the 
Expires header field and/or Expires parameter in the Contact header. When the value of the Expires header field and/or 
expires parameter in the Contact header is different than zero, then the P-CSCF shall: 

1) save the list of Service-Route headers preserving the order. The P-CSCF shall store this list during the entire 
registration period of the respective public user identity. The P-CSCF shall use this list to validate the routeing 
information in the requests originated by the UE. If this registration is a reregistration, the P-CSCF shall replace 
the already existing list of Service-Route headers with the new list; 

2) associate the Service-Route header list with the registered public user identity; 

3) store the public user identities found in the P-Associated-URI header value, including any associated display 
names, and associate them to the registered public user identity, i.e. the registered public user identity and its 
associated set of implicitly registered public user identities; 

4) store the default public user identity, including its associated display name, if provided, for use with procedures 
for the P-Asserted-Identity header. The default public user identity is the first on the list of URIs present in the P- 
Associated-URI header; 

NOTE 5: There can be more than one default public user identity stored in the P-CSCF, as the result of the multiple 
registrations of public user identities. 

5) store the values received in the P-Charging-Function- Addresses header; 

6) if a term-ioi parameter is received in the P-Charging- Vector header, store the value of the received term-ioi 
parameter; 

NOTE 6: Any received term-ioi parameter will be a type 1 term-ioi. The type 1 term-ioi identifies the home 
network of the registered user. 

7) if an existing set of security association is available, set the SIP level lifetime of the security association to the 
longest of either the previously existing security association lifetime, or the lifetime of the just completed 
registration plus 30 seconds; 

8) if a temporary set of security associations exists, change the temporary set of security associations to a newly 
established set of security associations, i.e. set its SIP level lifetime to the longest of either the previously 
existing set of security associations SIP level lifetime, or the lifetime of the just completed registration plus 30 
seconds; and 

9) protect the 200 (OK) response to the REGISTER request within the same security association to that in which 
the request was protected. 

When receiving a SIP message (including REGISTER requests) from the UE over the newly established set of security 
associations that have not yet been taken into use, the P-CSCF shall: 

1) reduce the SIP level lifetime of the old set of security associations towards the same UE to 64*T1 (if currently 
longer than 64*T1); and 

2) use the newly established set of security associations for further messages sent towards the UE as appropriate 
(i.e. take the newly established set of security associations into use). 

NOTE 7: In this case, the P-CSCF will send requests towards the UE over the newly established set of security 

associations. Responses towards the UE that are sent via UDP will be sent over the newly established set 
of security associations. Responses towards the UE that are sent via TCP will be sent over the same set of 
security associations that the related request was received on. 

NOTE 8: When receiving a SIP message (including REGISTER requests) from the UE over a set of security 

associations that is different from the newly established set of security associations, the P-CSCF will not 
take any action on any set of security associations. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



56 



ETSI TS 124 229 V7.6.0 (2006-12) 



When the SIP level lifetime of an old set of security associations is about to expire, i.e. their SIP level lifetime is 
shorther than 64*T1 and a newly established set of security associations has not been taken into use, the P-CSCF shall 
use the newly established set of security associations for further messages towards the UE as appropriate (see NOTE 5). 

When sending the 200 (OK) response for a REGISTER request that concludes a re-authentication, the P-CSCF shall: 

1) keep the set of security associations that was used for the REGISTER request that initiated the re-authentication; 

2) keep the newly established set of security associations created during this authentication; 

3) delete, if existing, any other set of security associations towards this UE immediately; and 

4) go on using for further requests sent towards the UE the set of security associations that was used to protect the 
REGISTER request that initiated the re-authentication. 

When sending the 200 (OK) respone for a REGISTER request that concludes an initial authentication, i.e. the initial 
REGISTER request was received unprotected, the P-CSCF shall: 

1) keep the newly established set of security associations created during this authentication; 

2) delete, if existing, any other set of security associations towards this UE immediately; and 

3) use the kept newly established set of security associations for further messages sent towards the UE. 

NOTE 9: The P-CSCF will maintain two Route header lists. The first Route header list - created during the 
registration procedure - is used only to validate the routeing information in the initial requests that 
originate from the UE. This list is valid during the entire registration of the respective public user identity. 
The second Route list - constructed from the Record Route headers in the initial INVITE and associated 
response - is used during the duration of the call. Once the call is terminated, the second Route list is 
discarded. 

The P-CSCF shall delete any security association from the IPsec database when their SIP level lifetime expires. 

The handling of the security associations at the P-CSCF is summarized in table 5.2.2-1. 

Table 5.2.2-1 : Handling of security associations at the P-CSCF 





Temporary set of security 
associations 


Newly established set of 
security associations 


Old set of security 
associations 


SIP message received over 
newly established set of 
security associations that 
have not yet been taken into 
use 


No action 


Take into use 


Reduce SIP level lifetime to 
64*T1 , if lifetime is larger 
than 64''T1 


SIP message received over 
old set of security 
associations 


No action 


No action 


No action 


Old set of security 
associations currently in use 
will expire in 64*T1 


No action 


Take into use 


No action 


Sending an authorization 
challenge within a 401 
(Unauthorized) response for 
a REGISTER request 


Create 

Remove any previously 
existing temporary set of 
security associations 


No action 


No action 


Sending 200 (OK) response 
for REGISTER request that 
concludes re-authentication 


Change to a newly 
established set of security 
associations 


Convert to and treat as old 
set of security associations 
(see next column) 


Continue using the old set 
of security associations over 
which the REGISTER 
request, that initiated the re- 
authentication was received. 
Delete all other old sets of 
security associations 
immediately 


Sending 200 (OK) response 
for REGISTER request that 
concludes initial 
authentication 


Change to a newly 
established set of security 
associations and take into 
use immediately 


Convert to old set of 
security associations, i.e. 
delete 


Delete 
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5.2.3 Subscription to tine user's registration-state event pacl^age 

Upon receipt of a 200 (OK) response to the initial REGISTER request, the P-CSCF shall: 

1) generate a SUBSCRIBE request in accordance with RFC 3680 [43], with the following elements: 

a Request-URI set to the resource to which the P-CSCF wants to be subscribed to, i.e. to a SIP URI that 
contains the default public user identity of the user; 

- a From header set to the P-CSCF's SIP URI; 

a To header, set to a SIP URI that contains the default public user identity of the user; 

an Event header set to the "reg" event package; 

an Expires header set to a value higher then the Expires header indicated in the 200 (OK) response to the 
REGISTER request; 

a P-Asserted-Identity header set to the SIP URI of the P-CSCF, which was inserted into the Path header 
during the registration of the user to whose registration state the P-CSCF subscribes to; and 

a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]; 

2) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in 
the visited network towards the home network, then the P-CSCF shall forward the request to an IBCF in the 
visited network; and 

3) determine the entry point of the home network (e.g., by using DNS services) and send the SUBSCRIBE request 
to that entry point, according to the procedures of RFC 3261 [26]. 

NOTE: The subscription to reg event package is done once per private user identity. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the P-CSCF shall store the information for the so 
established dialog and the expiration time as indicated in the Expires header of the received response. 

If continued subscription is required the P-CSCF shall automatically refresh the subscription by the reg event package 
600 seconds before the expiration time for a previously registered public user identity, either 600 seconds before the 
expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the 
initial subscription was for 1200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 
response, the P-CSCF shall still consider the original subscription valid for the duration of the most recently known 
"Expires" value according to RFC 3265 [28]. Otherwise, the P-CSCF shall consider the subscription invalid and start a 
new initial subscription according to RFC 3265 [28]. 

5.2.4 Registration of multiple public user icdentities 

Upon receipt of a 2xx response to the SUBSCRIBE request the P-CSCF shall maintain the generated dialog (identified 
by the values of the Call-ID, To and From headers). 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package of 
the user, the P-CSCF shall perform the following actions: 

1) for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered; 
and 

the state attribute within the <contact> sub-element is set to "active"; and 

the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's 
UE; and 

the event attribute of that <contact> sub-element(s) is set to "registered" or "created"; 

the P-CSCF shall: 

bind the indicated public user identity as registered to the contact information of the respective user;and 

add the public user identity to the list of the public user identities that are registered for the user; 
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2) for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered: 
and 

the state attribute within the <contact> sub-element is set to "terminated"; 

the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's 
UE; and 

the event attribute of that <contact> sub-element(s) is set to "deactivated", "expired", "probation", 
"unregistered", or "rejected"; 

the P-CSCF shall consider the indicated public user identitiy as deregistered for this user, and shall release all 
stored information for the public user identity bound to the respective user; and 

3) for each public user identity whose state attribute in the <registration> element is set to "terminated", i.e. 
deregistered; and 

the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's 
UE; and 

the event attribute of that <contact> sub-element(s) is set to "deactivated", "expired", "probation", 
"unregistered", or "rejected"; 

the P-CSCF shall consider the indicated public user identitiy as deregistered for this UE, and shall release all 
stored information for these public user identity bound to the respective user and remove the public user 
identity from the list of the public user identities that are registered for the user. 

If all public user identities, that were registered by the user using its private user identity, have been deregistered, the P- 
CSCF, will receive from the S-CSCF a NOTIFY request that may include the Subscription-State header set to 
"terminated", as described in subclause 5.4.2.1.2. If the Subscription-State header was not set to "terminated", the P- 
CSCF may either unsubscribe to the reg event package of the user or let the subscription expire. 

NOTE 1: Upon receipt of a NOTIFY request with the Subscription-State header set to "terminated", the P-CSCF 
considers the subscription to the reg event package terminated (i.e. as if the P-CSCF had sent a 
SUBSCRIBE request with an Expires header containing a value of zero). 

NOTE 2: There may be public user identities which are implicitly registered within the registrar (S-CSCF) of the 
user upon registration of one public user identity. The procedures in this subclause provide a mechanism 
to inform the P-CSCF about these implicitly registered public user identities. 

5.2.5 Deregistration 

5.2.5.1 User-initiated deregistration 

When the P-CSCF receives a 200 (OK) response to a REGISTER request (sent according to subclause 5.2.2) sent by 
this UE, it shall check the value of the Expires header field and/or expires parameter in the Contact header field. When 
the value of the Expires header field or expires parameter equals zero, then the P-CSCF shall: 

1) remove the public user identity found in the To header field, and all the associated public user identities, from 
the registered public user identities list belonging to this UE and all related stored information; and 

2) check if the UE has left any other registered public user identity. When all of the public user identities that were 
registered by this UE are deregistered, the P-CSCF shall delete the security associations towards the UE, after 
the server transaction (as defined in RFC 3261 [26]) pertaining to this deregistration terminates. 

NOTE 1 : Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to 
"terminated" (i.e. all public user identities are deregistered) and the Subscription-State header set to 
"terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the P- 
CSCF had sent a SUBSCRIBE request with an Expires header containing a value of zero). 

NOTE 2: There is no requirement to distinguish a REGISTER request relating to a registration from that relating to 
a deregistration. For administration reasons the P-CSCF may distinguish such requests, however this has 
no impact on the SIP procedures. 
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NOTE 3: When the P-CSCF has sent the 200 (OK) response for the REGISTER request of the only public user 
identity currently registered with its associated set of implicitly registered public user identities (i.e. no 
other is registered), the P-CSCF removes the security association established between the P-CSCF and 
the UE. Therefore further SIP signalling (e.g. the NOTIFY request containing the deregistration event) 
will not reach the UE. 

5.2.5.2 Network-initiated deregistration 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package of 
the UE, as described in subclause 5.2.3, including one or more <registration> element(s) which were registered by the 
UE with either: 

the state attribute set to "terminated"; or 

the state attribute set to "active" and the state attribute within the <contact> sub-element belonging to this UE set 
to "terminated", and the event attribute within the <contact> sub-element belonging to this UE set to "rejected" 
or "deactivated"; 

the P-CSCF shall remove all stored information for these public user identities for this UE and remove these public user 
identities from the list of the public user identities that are registered for the user. 

Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. 
all public user identities are deregistered) and the Subscription-State header set to "terminated" or when all public user 
identities of the UE have been deregistered, the P-CSCF shall shorten the security associations towards the UE. 

NOTE 1: The security association between the P-CSCF and the UEis shortened to a value that will allow the 
NOTIFY request containing the deregistration event to reach the UE. 

NOTE 2: When the P-CSCF receives the NOTIFY request with Subscription-State header containing the value of 
"terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the P- 
CSCF had sent a SUBSCRIBE request to the S-CSCF with an Expires header containing a value of zero). 

5.2.6 General treatment for all dialogs and standalone transactions 
excluding the REGISTER method 

5.2.6.1 Introduction 

The procedures of subclause 5.2.6 and its subclauses are general to all requests and responses, except those for the 
REGISTER method. 

5.2.6.2 Determination of UE-originated or UE-terminated case 

Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the P-CSCF shall: 

perform the procedures for the UE-terminating case as described in subclause 5.2.6.4 if the request makes use of 
the information for UE-terminating calls, which was added to the Path header entry of the P-CSCF during 
registration (see subclause 5.2.2), e.g. the message is received at a certain port or the topmost Route header 
contains a specific user part or parameter; 

perform the procedures for the UE-originating case as described in subclause 5.2.6.3 if this information is not 
used by the request. 

5.2.6.3 Requests initiated by the UE 

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the request 
contains a P-Preferred-Identity header that matches one of the registered public user identities, the P-CSCF shall 
identify the initiator of the request by that public user identity. 

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the request 
contains a P-Preferred-Identity header that does not match one of the registered public user identities, or does not 
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contain a P-Preferred-Identity header, the P-CSCF shall identify the initiator of the request by a default public user 
identity. If there is more than one default public user identity available, the P-CSCF shall randomly select one of them. 

NOTE 1 : The contents of the From header do not form any part of this decision process. 

NOTE 2: The display-name portion of the P-Preferred-Identity header and the registered public user identities is not 
included in the comparison to determine a match. 

When the P-CSCF receives from the UE an initial request for a dialog, and a Service-Route header list exists for the 
initiator of the request, the P-CSCF shall: 

1) verify that the list of URIs received in the Service-Route header (during the last successful registration or re- 
registration) matches the preloaded Route headers in the received request. This verification is done on a per URI 
basis, not as a whole string. If the verification fails, then the P-CSCFshall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 2 onwards; or 

b) replace the preloaded Route header value in the request with the value of the Service-Route header received 
during the last 200 (OK) response for a registration or reregistration; 

2) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in 
the visited network towards the home network, select an IBCF in the visited network and add the URI of the 
selected IBCF to the topmost Route header; 

NOTE 3: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point. 

3) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the port 
number of the P-CSCF in accordance with the procedures of RFC3261 [26], and either: 

a) the P-CSCF FQDN that resolves to the IP address, or 

b) the P-CSCF IP address; 

4) when adding its own SIP URI to the top of the Record-Route header, build the P-CSCF SIP URI in a format that 
contains the port number of the P-CSCF where it awaits subsequent requests from the called party, and either: 

a) the P-CSCF FQDN that resolves to the IP address; or 

b) the P-CSCF IP address; 

5) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value, 
including the display name if previously stored during registration representing the initiator of the request; 

6) add a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]; and 

7) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the 
request such that the P-CSCF is able to release the session if needed; 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any Ixx or 2xx response to the above request, the P-CSCF shall: 

1) store the values received in the P-Charging-Function- Addresses header; 

2) store the list of Record-Route headers from the received response; 

3) store the dialog ID and associate it with the private user identity and public user identity involved in the session; 

4) rewrite the port number of its own Record Route entry to its own protected server port number negotiated with 
the calling UE; and 

NOTE 4: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details on the selection of the protected port values see 3GPP TS 33.203 [19]. 

5) if the response corresponds to an INVITE request, save the Contact, From, To and Record-Route header field 
values received in the response such that the P-CSCF is able to release the session if needed; 
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before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives from the UE a target refresh request for a dialog, the P-CSCF shall: 

1) verify if the request relates to a dialog in which the originator of the request is involved: 

a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall 
answer the request by sending a 403 (Forbidden) response back to the originator. The P-CSCF will not 
forward the request. No other actions are required; or 

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue 
with the following steps; 

2) verify that the list of Route headers in the request matches the stored list of Record-Route headers for the same 
dialog. This verification is done on a per URl basis, not as a whole string. If the verification fails, then the P- 
CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 3 onwards; or 

b) replace the Route header value in the request with the stored list of Record-Route headers for the same 
dialog; 

3) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the port 
number of the P-CSCF where it awaits the responses to come, and either: 

a) the P-CSCF FQDN that resolves to the IP address, or 

b) the P-CSCF IP address; 

4) when adding its own SIP URI to the top of Record-Route header, build the P-CSCF SIP URI in a format that 
contains the port number of the P-CSCF where it awaits subsequent requests from the called party, and either: 

a) the P-CSCF FQDN that resolves to the IP address; or 

b) the P-CSCF IP address; and 

5) for INVITE dialogs (i.e. dialogs initiated by an INVITE request), replace the saved Contact and Cseq header 
filed values received in the request such that the P-CSCF is able to release the session if needed; 

NOTE 5: The replaced Contact header field value is valid only if a Ixx or 2xx response will be received for the 
request. In other cases the old value is still valid. 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives a Ixx or 2xx response to the above request, the P-CSCF shall: 

1) rewrite the port number of its own Record Route entry to the same value as for the response to the initial request 
for the dialog; and 

2) replace the saved Contact header value received in the response such that the P-CSCF is able to release the 
session if needed; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives from the UE the request for a standalone transaction, and a Service-Route header list exists 
for the initiator of the request, the P-CSCF shall: 

1) verify that the list of URIs received in the Service-Route header (during the last successful registration or re- 
registration) matches the preloaded Route headers in the received request. This verification is done on a per URI 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 3 onwards; or 

b) replace the preloaded Route header value in the request with the one received during the last registration in 
the Service-Route header of the 200 (OK) response; 
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2) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in 
the visited network towards the home network, select an IBCF in the visited network and add the URI of the 
selected IBCF to the topmost Route header; 

NOTE 6: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point. 

3) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value, 
including the display name if previously stored during registration, representing the initiator of the request; and 

4) add a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]; 
before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) store the values received in the P-Charging-Function- Addresses header; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including requests 
relating to an existing dialog where the method is unknown), the P-CSCF shall: 

1) verify if the request relates to a dialog in which the originator of the request is involved: 

a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall 
answer the request by sending a 403 (Forbidden) response back to the originator. The P-CSCF will not 
forward the request. No other actions are required; or 

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue 
with the following steps; 

2) verify that the list of Route headers in the request matches the stored list of Record-Route headers for the same 
dialog. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P- 
CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 3 onwards; or 

b) replace the Route header value in the request with the stored list of Record-Route headers for the same 
dialog; 

3) for dialogs that are not INVITE dialogs, add a P-Charging- Vector header with the icid parameter populated as 
specified in 3GPP TS 32.260 [17]; and 

4) for INVITE dialogs, replace the saved Cseq header value received in the request such that the P-CSCF is able to 
release the session if needed; 

before forwarding the request, (based on the topmost Route header,) in accordance with the procedures of 
RFC 3261 [26]. 

When the P-CSCF receives from the UE the request for an unknown method (that does not relate to an existing dialog), 
and a Service-Route header list exists for the initiator of the request, the P-CSCF shall: 

1) verify that the list of URIs received in the Service-Route header (during the last successful registration or re- 
registration) is included, preserving the same order, as a subset of the preloaded Route headers in the received 
request. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P- 
CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 2 onwards; or 

b) replace the Route header value in the request with the one received during the last registration in the Service- 
Route header of the 200 (OK) response; 
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2) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in 
the visited network towards the home network, then the P-CSCF shall select an IBCF in the visited network and 
add the URI of the selected IBCF to the topmost Route header; and 

NOTE 7: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point. 

3) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value, 
including the display name if previously stored during registration, representing the initiator of the request; 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

5.2.6.4 Requests terminated by the UE 

When the P-CSCF receives, destined for the UE, an initial request for a dialog, prior to forwarding the request, the P- 
CSCF shall: 

1) convert the list of Record-Route header values into a list of Route header values and save this list of Route 
headers; 

2) if the request is an INVITE request, save a copy of the Contact, CSeq and Record-Route header field values 
received in the request such that the P-CSCF is able to release the session if needed; 

3) when adding its own SIP URI to the top of the list of Record-Route headers and save the list, build the P-CSCF 
SIP URI in a format that contains the protected server port number of the security association established from 
the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

4) when adding its own address to the top of the received list of Via header and save the list, build the P-CSCF Via 
header entry in a format that contains the protected server port number of the security association established 
from the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 1 : The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

5) remove and store the values received in the P-Charging-Function- Addresses header; 

6) remove and store the icid parameter received in the P-Charging- Vector header; and 

7) save a copy of the P-Called-Party-ID header; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives any Ixx or 2xx response to the above request, the P-CSCF shall: 

1) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with the value saved 
from the P-Called-Party-ID header that was received in the request, plus the display name if previously stored 
during registration, representing the initiator of the response; 

2) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 
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3) verify that the list of URIs received in the Record-Route header of the request corresponding to the same dialog 
is included, preserving the same order, as a subset of the Record-Route header list of this response. This 
verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall 
either: 

a) discard the response; or 

b) replace the Record-Route header values with those received in the request, rewrite the port number of its own 
Record-Route entry to the port number where it awaits subsequent requests from the calling party and 
remove the comp parameter. 

If the verification is successful, the P-CSCF shall rewrite the port number of its own Record-Route entry to 
the port number where it awaits subsequent requests from the calling party and remove the comp parameter; 

4) store the dialog ID and associate it with the private user identity and public user identity involved in the session; 
and 

5) if the response corresponds to an INVITE request, save the Contact, To, From and Record-Route header field 
value received in the response such that the P-CSCF is able to release the session if needed; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any other response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved Ust of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the request, 
the P-CSCF shall: 

1) add its own address to the top of the received list of Via header and save the list. The P-CSCF Via header entry 
is built in a format that contains the protected server port number of the security association established from the 
UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 2: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) when adding its own SIP URI to the top of the list of Record-Route headers and save the list, build the P-CSCF 
SIP URI in a format that contains the protected server port number of the security association established from 
the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; and 

3) for INVITE dialogs, replace the saved Contact and Cseq header field values received in the request such that the 
P-CSCF is able to release the session if needed; 

NOTE 3: The replaced Contact header field value is valid only if a Ixx or 2xx response will be received for the 
request. In other cases the old value is still valid. 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives a Ixx or 2xx response to the above request, the P-CSCF shall: 
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1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

2) rewrite the port number of its own Record-Route entry to the same value as for the response to the initial request 
for the dialog and remove the comp parameter; and 

3) replace the saved Contact header field value received in the response such that the P-CSCF is able to release the 
session if needed; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any other response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; and 

2) rewrite the port number of its own Record-Route entry to the port number where it awaits subsequent requests 
from the calling party and remove the comp parameter; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives, destined for the UE, a request for a standalone transaction, or a request for an unknown 
method (that does not relate to an existing dialog), prior to forwarding the request, the P-CSCF shall: 

1) add its own address to the top of the received list of Via header and save the list. The P-CSCF Via header entry 
is built in a format that contains the protected server port number of the security association established from the 
UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 4: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) store the values received in the P-Charging-Function- Addresses header; 

3) remove and store the icid parameter received in the P-Charging- Vector header; and 

4) save a copy of the P-Called-Party-ID header; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; and 

2) remove the P-Preferred-Identity header, if present, and insert an P-Asserted-Identity header with the value saved 
from the P-Called-Party-ID header of the request, plus the display name if previously stored during registration, 
representing the initiator of the response; 
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before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target refresh request 
(including requests relating to an existing dialog where the method is unknown), prior to forwarding the request, the P- 
CSCF shall: 

1) add its own address to the top of the received list of Via header and save the list The P-CSCF Via header entry is 
built in a format that contains the protected server port number of the security association established from the 
UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 5: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) remove and store the icid parameter from P-Charging-Vector header; and 

3) for INVITE dialogs, replace the saved Cseq header value received in the request such that the P-CSCF is able to 
release the session if needed; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

5.2.7 Initial INVITE 

5.2.7.1 Introduction 

In addition to following the procedures for initial requests defined in subclause 5.2.6, initial INVITE requests also 
follow the procedures of this subclause. 

5.2.7.2 UE-originating case 

When the P-CSCF receives from the UE an INVITE request, the P-CSCF may require the periodic refreshment of the 
session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, it shall apply the 
procedures described in RFC 4028 [58] clause 8. 

NOTE 1: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

The P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response. 

Upon receiving a response as specified in RFC 3313 [31] to the initial INVITE request, the P-CSCF shall: 

if a media authorization token is generated by the PDF (i.e. when service-based local policy control is applied), 
insert the P-Media- Authorization header containing that media authorization token. 
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NOTE 2: Typically, the first 183 (Session Progress) response contains an SDP answer including one or more "m=" 
media descriptions, but it is also possible that the response does not contain an SDP answer or the SDP 
does not include at least an "m=" media description. However, the media authorization token is generated 
independently of the presence or absence of "m=" media descriptions and sent to the UE in the P-Media- 
Authorization header value. The same media authorization token is used until the session is terminated. 
For further details see 3GPP TS 29.207 [12]. 

The P-CSCF shall also include the access-network-charging-info parameter (if received via the PDF, over the Go and 
Gq interfaces) in the P-Charging-Vector header in the first request originated by the UE that traverses the P-CSCF, as 
soon as the charging information is available in the P-CSCF, e.g., after the local resource reservation is complete. 
Typically, this first request is an UPDATE request if the remote UA supports the "integration of resource management 
in SIP" extension or a re-INVITE request if the remote UA does not support the "integration of resource management in 
SIP" extension. See subclause 5.2.7.4 for further information on the access network charging information. 

5.2.7.3 UE-terminating case 

When the P-CSCF receives an INVITE request destined for the UE the P-CSCF may require the periodic refreshment of 
the session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, it shall apply the 
procedures described in RFC 4028 [58] clause 8. 

NOTE 1: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 

cannot automatically be granted, i.e. at least one of the involved UEs needs to support it in order to make 
it work. 

When the P-CSCF receives an initial INVITE request destined for the UE, it will contain the Contact URI of the UE in 
the Request-URI, and a single preloaded Route header. The received initial INVITE request will also have a list of 
Record-Route headers. Prior to forwarding the initial INVITE to the URI found in the Request-URI, the P-CSCF shall: 

if a media authorization token is generated by the PDF as specified in RFC 3313 [31] (i.e. when service-based 
local policy control is applied), insert the P-Media-Authorization header containing that media authorization 
token. 

NOTE 2: Typically, the initial INVITE request contains an SDP offer including one or more "m=" media 

descriptions, but it is also possible that the INVITE request does not contain an SDP offer or the SDP 
does not include at least an "m= media description. However, the media authorization token is generated 
independently of the presence or absence of "m=" media descriptions and sent to the UE in the P-Media- 
Authorization header value. The same media authorization token is used until the session is terminated. 
For further details see 3GPP TS 29.207 [12]. 

In addition, the P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response. 

The P-CSCF shall also include the access-network-charging-info parameter (if received via the PDF, over the Go and 
Gq interfaces) in the P-Charging-Vector header in the first request or response originated by the UE that traverses the P- 
CSCF, as soon as the charging information is available in the P-CSCF e.g., after the local resource reservation is 
complete. Typically, this first response is a 180 (Ringing) or 200 (OK) response if the remote UA supports the 
"integration of resource management in SIP" extension, or a re-INVITE request if the remote UA does not support the 
"integration of resource management in SIP" extension. See subclause 5.2.7.4 for further information on the access 
network charging information. 

5.2.7.4 Access network charging information 

The P-CSCF shall include the access-network-charging-info parameter within the P-Charging- Vector header as 
described in subclause 7.2A.5. 
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5.2.8 Call release 

5.2.8.1 P-CSCF-initiated call release 

5.2.8.1 .1 Cancellation of a session currently being established 

Upon receipt of an indication that radio coverage is no longer available for a multimedia session currently being 
established (e.g. abort session request from PDF), the P-CSCF shall cancel that dialog by sending out a CANCEL 
request that includes a Reason header containing a 503 (Service Unavailable) status code according to the procedures 
described in RFC 3261 [26] and RFC 3326 [34A]. 

Upon receipt of an indication that QoS resources are no longer available for a multimedia session currently being 
established, the P-CSCF shall cancel that dialog by responding to the original INVITE request with a 503 (Servi ce 
Unavailable) response, and by sending out a CANCEL request to the INVITE request towards the terminating UE that 
includes a Reason header containing a 503 (Service Unavailable) status code according to the procedures described in 
RFC 3261 [26] and RFC 3326 [34A]. 

5.2.8.1 .2 Release of an existing session 

Upon receipt of an indication that the radio/bearer interface resources are no longer available for a session (e.g. abort 
session request from PDF) or upon detecting that the SDP offer conveyed in a SIP response contained parameters which 
are not allowed according to the local policy (as specified in the subclause 6.2), the P-CSCF shall release the respective 
dialog by applying the following steps: 

1) if the P-CSCF serves the calling user of the session it shall generate a BYE request based on the information 
saved for the related dialog, including: 

a Request-URI, set to the stored Contact header provided by the called user; 

a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE request; 

a From header, set to the From header value as received in the initial INVITE request; 

a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

a CSeq header, set to the current CSeq value stored for the direction from the calling to the called user, 
incremented by one; 

a Route header, set to the routeing information towards the called user as stored for the dialog; 

a Reason header that contains: 

a 503 (Service Unavailable) response code, if radio/bearer interface resources are no longer available; or 

a 488 (Not Acceptable Here) response code, if a SDP offer conveyed in a SIP response contained 
parameters which are not allowed according to the local policy; and 

further headers, based on local policy. 

2) If the P-CSCF serves the called user of the session it shall generate a BYE request based on the information 
saved for the related dialog, including: 

a Request-URI, set to the stored Contact header provided by the calling user; 

a To header, set to the From header value as received in the initial INVITE request; 

a From header, set to the To header value as received in the 200 (OK) response for the initial INVITE 
request; 

a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

a CSeq header, set to the current CSeq value stored for the direction from the called to the calling user, 
incremented by one; 
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a Route header, set to the routeing information towards the calling user as stored for the dialog; 

a Reason header that contains: 

a 503 (Service Unavailable) response code, if radio/bearer interface resources are no longer available; or 

- a 488 (Not Acceptable Here) response code, if SDP payload contained parameters which are not allowed 
according to the local policy; and 

further headers, based on local policy. 

3) send the so generated BYE request towards the indicated user. 

4) upon receipt of the 2xx responses for the BYE request, shall delete all information related to the dialog and the 
related multimedia session. 

5.2.8.1.3 Abnormal cases 

Upon receipt of a request on a dialog for which the P-CSCF initiated session release, the P-CSCF shall terminate this 
received request and answer it with a 481 (Call/Transaction Does Not Exist) response. 

5.2.8.1 .4 Release of the existing dialogs due to registration expiration and deletion of the 
security association 

If there are still active dialogs associated with the user after the security associations were deleted, the P-CSCF shall 
discard all information pertaining to these dialogs without performing any further SIP transactions with the peer entities 
of the P-CSCF. 

NOTE: At the same time, the P-CSCF will also indicate via the Gq interface that the session has been terminated. 

5.2.8.2 Call release initiated by any other entity 

When the P-CSCF receives a 2xx response for a BYE request matching an existing dialog, it shall delete all the stored 
information related to the dialog. 

5.2.8.3 Session expiration 

If the P-CSCF requested the session to be refreshed periodically, and the P-CSCF got the indication that the session will 
be refreshed, when the session timer expires, the P-CSCF shall delete all the stored information related to the dialog. 

NOTE: The P-CSCF will also indicate to the IP -CAN, via the Gq interface, that the session has terminated. 

5.2.9 Subsequent requests 

5.2.9.1 UE-originating case 

The P-CSCF shall respond to all relNVITE requests with a 100 (Trying) provisional response. 

For a relNVITE request or UPDATE request from the UE within the same dialog, the P-CSCF shall include the updated 
access-network-charging-info parameter from P-Charging- Vector header when sending the SIP request to the S-CSCF. 
See subclause 5.2.7.4 for further information on the access network charging information. 

5.2.9.2 UE-terminating case 

The P-CSCF shall respond to all relNVITE requests with a 100 (Trying) provisional response. 

For a relNVITE request or UPDATE request destined towards the UE within the same dialog, when the P-CSCF sends 
200 (OK) response (to the INVITE request or UPDATE request) towards the S-CSCF, the P-CSCF shall include the 
updated access-network-charging-info parameter in the P-Charging-Vector header. See subclause 5.2.7.4 for further 
information on the access network charging information. 
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5.2.10 Emergency service 



Editor's note: This subclause needs further study related to the support of emergency sessions in NGN. Emergency 
calls are not covered in the present document and therefore the handling of any session recognised as an 
emergency session is not specified. In particular the 380 (Alternative Service) response may not be 
appropriate. 

5.2.10.1 General 

Editor's Note: The requirements for handling emergency related requests that have not been received over a security 
association need to be derived from the related statements in the UE section. 

The P-CSCF can handle emergency session and other requests from both a registered user as well as an unregistered 
user. Certain networks only allow emergency session from registered users. 

Editor's note: It needs to be clarified whether a user can set up an emergency session if the user is not registered. 

From the requirements in 23.167 it seems that even in the case of a UICC not being available, the UE still 
needs to register. In that case, the P-CSCF would (in the above sentence) only be able to handle 
emergency sessions from registered users. The user then could be either authenticated or not. 

NOTE 1 : If only emergency setup from registered users is allowed, a request from an unregistered user is ignored 
since it is received outside of the security association. The P-CSCF shall not subscribe to the reg event 
package for any emergency public user identity. 

The P-CSCF shall store a configurable list of local emergency service identifiers, i.e. emergency numbers and the 
emergency service URN, which are valid for the operator to which the P-CSCF belongs to. In addition to that, the P- 
CSCF shall store a configurable list of roaming partners' emergency service identifiers, i.e. emergency numbers and 
emergency service URN associated with MCC and MNC codes. 

NOTE 2: The emergency service URN are common to all networks, although subtypes may either not necessarily 
be in use, or a different set of subtypes is in use. The above requirements do not apply to subtypes of the 
emergency service URN. 

In order to determine whether the intial request for a dialog or standalone transaction or an unknown method is destined 
for a PSAP in the roaming country (i.e. the list of roaming partners' are inspected): 

the P-CSCF shall compare the MCC and the MNC fields if received in the P- Access-Network-Info header of the 
initial request for a dialog or standalone transaction or unknown method against its own MCC and MNC codes; 
or 

if no P- Access-Network-Info header is received or a P- Access-Network-Info header is received not containing 
MCC and MNC fields in the initial request for a dialog or standalone transaction or unknown method, the P- 
CSCF shall apply the local service identifiers. 

Editor's note: The handling in a roaming scenario when no MCC and MNC is received from the UE needs further 
investigation. 

NOTE 3: Depending on local operator policy, the P-CSCF has the capability to reject requests relating to specific 
methods in accordance with RFC 3261 [26], as an alternative to the functionality described above. 

When the P-CSCF responds that the CS domain is to be used for emergency call the P-CSCF shall include in the 380 
(Alternative Service) response a Content-Type header field with the value set to associated MIME type of the 3GPP 
IMS XML body as described in subclause 7.6.1. 

The P-CSCF shall include in the 3GPP IMS XML body: 

a) an <alternative-service> element, set to the parameters of the alternative service: 

b) a <type> child element, set to "emergency" to indicate that it was an emergency call; and 

c) a <reason> child element, set to an operator configurable reason. 

The P-CSCF can handle emergency session establishment within a non-emergency registration. 
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When the P-CSCF responds that an emergency registration is required the P-CSCF shall include in the 380 (Alternative 
Service) response a Content-Type header field with the value set to associated MIME type of the 3GPP IMS XML body 
as described in subclause 7.6.1. The P-CSCF shall include in the 3GPP IMS XML body: 

a) an <alternative-service> element, set to the parameters of the alternative service; 

b) a <type> child element, set to "emergency" to indicate that it was an emergency call; and 

c) an <action> child element, set to "emergency-registration" to indicate that emergency registration is required; 
and 

d) a <reason> child element, set to an operator configurable reason. 

NOTE 4: <action> element is used only in a context to indicate the UE that emergency registration is requied in the 
present document. Therefore, this element is defined as optional and shall not be used in other purpose. 

For all SIP transactions identified as relating to an emergency, the P-CSCF shall give priority over other transactions. 
This allows special treatment (e.g. with respect to filtering, higher priority, routeing) of emergency sessions. The exact 
meaning of priority is not defined further in this document, but is left to national regulation and network configuration. 

5.2.1 0.2 General treatment for all dialogs and standalone transactions excluding the 
REGISTER method - from an unregistered user 

Editor's Note: It is proposed to move this subclause to the very end of subclause 5.2. 10. This has not been done here, 
in order to show which text is newly introduced (due to revision marks). 

Editor's Note: It is assumed that the only case in which a emergency INVITE can be received from an unregistered 
user is, when in the related UE no UICC is available. Nevertheless TS 23.167 states, that even these UEs 
must register via an emergency APN prior to sending an emergency INVITE request. It is therefore not 
clear whether this subclause is at all in-line with stage 2 requirements. 

If the P-CSCF receives an initial request for a dialog or standalone transaction, or an unknown method for an 
unregistered user, the P-CSCF shall inspect the Request URI independent of values of possible entries in the received 
Route headers for known emergency service identifiers, i.e. emergency numbers and the emergency service URN from 
the configurable lists. If the P-CSCF detects that the Request-URI of the initial request for a dialog or standalone 
transaction, or unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF 
shall: 

1) include in the Request-URI an emergency service URN, i.e. with a service type of "sos" in accordance with 
draft-ietf-ecrit-service-urn [69]. An additional sub-service type can be added if information on the type of 
emergency service is known. The entry in the Request-URI that the P-CSCF includes may either be: 

as received in the Request URI from the UE in accordance with draft-ietf-ecrit-service-urn [67]; or 

as deduced from the Request-URI received from the UE; 

2) include the value "emergency" in the Priority header; 

3) select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header; and 
NOTE 1 : How the list of E-CSCF is obtained by the P-CSCF is implementation dependent. 

4) execute the procedure described in subclause 5.2.6.3 dealing with the procedure when the P-CSCF receives an 
initial request from the UE and subclause 5.2.7.2 except for: 

verifying the preloaded route against the received Service-Route header; 

removing the P-Preferred-Identity header; and 

inserting a P-Asserted-Identity header. 

Editor's Note: For certain IP-CAN the P-CSCF can receive location information that is transported to the E-CSCF. 
This will be described in the IP-CAN related section. 

Editor's note: Whether the P-CSCF shall add any identity into the P-Asserted-Identity header requires further study. 
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If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction or unknown 
method (including its retransmissions); or receives a 3xx response or 480 (Temporarily Unavailable) response to an 
INVITE request, the P-CSCF shall select a new IBCF or E-CSCF and forward the request. 

When the P-CSCF receives a target refresh request from the UE for a dialog, the P-CSCF shall execute the procedure 
described in step 1) to 5), in paragraph of subclause 5.2.6.3 describing the procedure when the P-CSCF receives a target 
refresh request. 

When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including requests 
relating to an existing dialog where the method is unknown), the P-CSCF shall execute the procedure described in step 
1) to 4), in the paragraph of subclause 5.2.6.3 describing the procedure when the P-CSCF receives a subsequent request. 

When the P-CSCF receives any Ixx or 2xx response to the above requests, the P-CSCF shall execute the appropriate 
procedure for the type of request described in subclause 5.2.6.3, except that the P-CSCF shall not rewrite the port 
number of its own Record-Route entry. 

When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the request, 
the P-CSCF shall execute the procedure described in step 3, the paragraph of subclause 5.2.6.4 describing when the P- 
CSCF receives a target refresh request. 

When the P-CSCF receives a Ixx or 2xx response to the above request the P-CSCF shall execute the procedure 
described in step 1) to 3) in the paragraph of subclause 5.2.6.4 describing when the P-CSCF receives Ixx or 2xx 
response to a target request. 

When the P-CSCF receives any other response to the above request the P-CSCF shall execute the procedure described 
in step 1) to 2) in the paragraph of subclause 5.2.6.4 describing when the P-CSCF receives any other response to a 
target request. 

When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target refresh request 
(including requests relating to an existing dialog where the method is unknown), prior to forwarding the request, the P- 
CSCF shall execute the procedure described in steps 2 and 3 of subclause 5.2.6.4 describing when a P-CSCF receives a 
subsequent request. 

When the P-CSCF receives any other response to the above request the P-CSCF shall execute the procedure described 
in step 1 in the paragraph of subclause 5.2.6.4 describing when the P-CSCF receives any other response to a subsequent 
request. 

5.2.1 0.3 General treatment for all dialogs and standalone transactions excluding the 
REGISTER method after emergency registration 

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a 
registered user the P-CSCF shall inspect the Request URI independent of values of possible entries in the received 
Route headers for known emergency service identifiers, i.e. emergency numbers and the emergency service URN from 
these configurable lists. If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone 
transaction, or an unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF 
shall: 

1) include in the Request-URI an emergency service URN, i.e. with a service type of "sos" as specified in draft-ietf- 
ecrit-service-urn [69], if necessary, and execute the procedure described in step 3, 4, 5, and 6, in 

subclause 5.2.6.3 dealing with the procedure when the P-CSCF receives an initial request from the UE. The entry 
in the Request-URI that the P-CSCF includes may either be: 

as received from the UE in the Request URI in accordance with draft- ietf-ecrit-service-urn-01 [67]; or 

as deduced from the Request-URI received from the UE. 

In addition the P-CSCF shall execute the procedures as specified in subclause 5.2 with the following additions: 

2) the P-CSCF shall: 

if the emergency public user identity is included in the P-Preferred-Identity header, remove the P-Preferred- 
Identity header from the received request and insert a P-Asserted-Identity header that includes the emergency 
public user identity that was present in the P-Preferred-Identity header. Add a second P-Asserted identity 
header that contains the the tel URI associated with the emergency public user identity. If the tel URI 
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associated with the emergency public user identity is included in the P-Preferred-Identity header, check the 
validity of the tel URI, remove the P-Preferred-Identity header and insert a P-Asserted-Identity header that 
includes the tel URI that was present in the P-Preferred-Identity header. Add a second P-Asserted-Identity 
header that contains the emergency public user identity; 

include the value "emergency" in the Priority header; and 

select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header. 

NOTE: It is implementation dependant as to how the P-CSCF obtains the list of E-CSCFs. 

Editor's Note; For certain IP-CAN the P-CSCF can receive location information that is transported to the E-CSCF. 
This will be described in the IP-CAN related section. 

If the P-CSCF does not receive any response to the INVITE request (including its retransmissions); or receives a 3xx 
response or 480 (Temporarily Unavailable) response to an INVITE request, the P-CSCF shall select a new E-CSCF and 
forward the INVITE request. 

5.2.1 0.4 General treatment for all dialogs and standalone transactions excluding the 
REGISTER method - non-emergency registration 

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a 
registered user the P-CSCF shall inspect the Request URI independent of values of possible entries in the received 
Route headers for known emergency service identifiers, i.e. emergency numbers and the emergency service URN from 
these configurable lists. If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone 
transaction, or an unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF 
shall: 

1) include in the Request-URI an emergency service URN, i.e. with a service type of "sos" as specified in draft-ietf- 
ecrit-service-urn [69], if necessary, and execute the procedure described in step 2, 3, 4, 5, and 6, in 

subclause 5.2.6.3 dealing with the procedure when the P-CSCF receives an initial request from the UE. The entry 
in the Request-URI that the P-CSCF includes may either be: 

as received from the UE in the Request URI in accordance with draft-ietf-ecrit-service-urn-01 [67]; or 

as deduced from the Request-URI received from the UE. 

In addition the P-CSCF shall execute the procedures as specified in subclause 5.2 with the following additions: 

2) the P-CSCF shall: 

insert the public user identity and an associated tel-URI in the P-Asserted-Identity header, if a public user 
identity is provided by the UE; or check the validity of the tel URI and then insert the tel URI and an 
associated public user identity in the P-Asserted-Identity header, if a tel-URI is provided by the UE; 

include the value "emergency" in the Priority header; and 

select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header. 

NOTE: It is implementation dependant as to how the P-CSCF obtains the list of E-CSCFs. 

Editor's Note: For certain IP -CAN the P-CSCF can receive location information that is transported to the E- 
CSCF. This will be described in the IPCAN related section. 

If the P-CSCF does not receive any response to the INVITE request (including its retransmissions); or receives a 3xx 
response or 480 (Temporarily Unavailable) response to an INVITE request, the P-CSCF shall select a new E-CSCF and 
forward the INVITE request. 

5.2.10.5 Abnormal cases 

If the IM CN subsystem to where the P-CSCF belongs to is not capable to handle emergency sessions or due to local 
policy does not handle emergency sessions or only handles certain type of emergency session request, the P-CSCF shall 
not forward the INVITE request. The P-CSCF shall respond to the INVITE request with a 380 (Alternative Service) 
response, see subclause 5.2.10.1. 
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NOTE: Some networks only allow session requests which are in accordance with draft-ietf-ecrit-service-urn [67]. 

5.2.11 Void 

5.3 Procedures at the l-CSCF 

5.3.1 Registration procedure 

5.3.1.1 General 

During the registration procedure the I-CSCF shall behave as a stateful proxy. 

5.3.1.2 Normal procedures 

When the I-CSCF receives a REGISTER request, the I-CSCF shall verify whether or not it has arrived from a trusted 
domain. If the request has not arrived from a trusted domain, the I-CSCF shall complete the processing of the request by 
responding with 403 (Forbidden) response. Otherwise, the I-CSCF starts the user registration status query procedure to 
the HSS as specified in 3GPP TS 29.228 [14]. 

NOTE 1 : The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures 
described in 3GPP TS 33.210 [19A]. 

NOTE 2: Different UEs, each with its own private user identity, can register the same shared public user identity. 
Registrations of all public user identities belonging to these UEs are directed to the same S-CSCF as 
described in 3GPP TS 29.228 [14]. 

Prior to performing the user registration query procedure to the HSS, the I-CSCF decides which HSS to query, possibly 
as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 3GPP TS 29.228 [14]. As a 
result of the query the I-CSCF gets the Redirect-Host AVP. 

If the user registration status query response from the HSS includes a valid SIP URI, the I-CSCF shall: 

1) replace the Request-URI of the received REGISTER request with the SIP URI received from the HSS in the 

Server-Name AVP; 

2) optionally include the received Redirect-Host AVP value in the P-User-Database header as defined in 

RFC 4457 [82]; and 

3) forward the REGISTER request to the indicated S-CSCF. 

NOTE 3: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

If the user registration status query response from the HSS includes a list of capabilities, the I-CSCF shall: 

1) select a S-CSCF that fulfils the indicated mandatory capabilities - if more than one S-CSCFs fulfils the indicated 
mandatory capabilities the S-CSCF which fulfils most of the possibly additionally indicated optional capabilities; 

2) replace the Request-URI of the received REGISTER request with the URI of the S-CSCF; 

3) optionally, include the received Redirect-Host AVP value in the P-User-Database header as defined in 

RFC 4457 [82]; and 

4) forward the REGISTER request to the selected S-CSCF. 

NOTE 4: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

When the I-CSCF receives a 2xx response to a REGISTER request, the I-CSCF shall proxy the 2xx response to the P- 
CSCF. 
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5.3.1.3 Abnormal cases 

In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 403 
(Forbidden) response to the UE. 

If the HSS sends a negative response to the user registration status query request, the I-CSCF shall send back a 403 
(Forbidden) response. 

If the the user registration status query procedure cannot be completed, e.g. due to time-out or incorrect information 
from the HSS, the I-CSCF shall send back a 480 (Temporarily Unavailable) response to the UE. 

If a selected S-CSCF: 

does not respond to the REGISTER request and its retransmissions by the I-CSCF; or 

sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

and: 

the REGISTER request did not include an "integrity-protected" parameter in the Authorization header; or 
did include an "integrity-protected" parameter with a value different from "yes" in the Authorization header; 

then: 

if the I-CSCF has received the list of capabilities from the HSS, the I-CSCF shall select a new S-CSCF as 
described in subclause 5.3.1.2, based on the capabilities indicated from the HSS. The newly selected S-CSCF 
shall not be one of any S-CSCFs selected previously during this same registration procedure; or 

if the I-CSCF has received a valid SIP URI from the HSS because the S-CSCF is already assigned to other UEs 
sharing the same public user identity, it will request the list of capabilities from the HSS and, on receiving these 
capabilities, the I-CSCF shall select a new S-CSCF as described in subclause 5.3.1.2, based on the capabilities 
indicated from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during 
this same registration procedure. 

If a selected S-CSCF does not respond to a REGISTER request and its retransmissions by the I-CSCF and the 
REGISTER request did include an Authorization header with the "integrity-protected" parameter set to "yes", the I- 
CSCF shall send back a or 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 
[26]. 

If the I-CSCF cannot select a S-CSCF which fulfils the mandatory capabilities indicated by the HSS, the I-CSCF shall 
send back a 600 (Busy Everywhere) response to the user. 

5.3.2 Initial requests 
5.3.2.1 Normal procedures 

The I-CSCF may behave as a stateful proxy for initial requests. 

Upon receipt of a request, the I-CSCF shall perform the originating procedures as described in subclause 5.3.2. 1 A if the 
topmost Route header of the request contains the "orig" parameter. Otherwise, the I-CSCF shall continue with the rest 
of the procedures of this subclause. 

When the I-CSCF receives a request, the I-CSCF shall verify whether it has arrived from a trusted domain or not. If the 
request has arrived from a non trusted domain, then the I-CSCF shall remove all P-Asserted-Identity headers, all P- 
Access-Network-Info headers, all P-Charging-Vector headers and all P-Charging-Function- Addresses headers the 
request may contain. 

NOTE 1 : The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures 
described in 3GPP TS 33.210 [19A]. 

The I-CSCF shall discard the P-Profile Key header, if the I-CSCF receives the Profile Key header in a SIP request or 
response. 
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When the I-CSCF receives, destined for a server user or a PSI, an initial request for a dialog or standalone transaction 
the I-CSCF shall: 

1) if the Request-URI includes: 

a) a pres: or an im: URI, then translate the pres: or im: URI to a public user identity and replace the Request- 
URI of the incoming request with that public user identity; or 

b) a SIP -URI that is not a GRUU and with the user part starting with a + and the user parameter equals "phone" 
then replace the Request-URI with a tel-URI with the user part of the SIP-URI in the telephone-subscriber 
element in the tel-URI; or 

c) a SIP URI that is a GRUU, then obtain the public user identity from the Request-URI and use it for location 
query procedure to the HSS. When forwarding the request, the I-CSCF shall not modify the Request-URI of 
the incoming request; 

NOTE 2: If the Request-URI is a GRUU with the user part starting with a + and the user parameter equals "phone", 
the I-CSCF builds a tel URI from the user part and uses it only to query the HSS. Subsequently, when the 
I-CSCF forwards the request to the S-CSCF, it will not modify the Request-URI. 

NOTE 3: SRV records have to be advertised in DNS pointing to the I-CSCF for pres: and im: queries. 

2) remove a Route header, if present; and 

3) check if the domain name of the Request-URI matches with one of the PSI subdomains configured in the I- 
CSCF. If the match is successful, the I-CSCF resolves the Request-URI by an internal DNS mechanism into the 
IP address of the AS hosting the PSI and does not start the user location query procedure. Otherwise, the I-CSCF 
will start the user location query procedure to the HSS as specified in 3GPP TS 29.228 [14] for the called PSI or 
user, indicated in or derived from the Request-URI. Prior to performing the user location query procedure to the 
HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator 
Functional (SLF) entity as specified in 3GPP TS 29.228 [14]. 

When the I-CSCF receives any response to such a request, the I-CSCF shall store the value of the term-ioi parameter 
received in the P-Charging-Vector header, if present. 

NOTE 4: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the service 
provider from which the response was sent. 

When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid 
hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE 5: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

In case the I-CSCF is able to resolve the Request-URI into the IP address of the AS hosting the PSI, then it shall: 

1) store the value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in 
the P-Charging- Vector header. If no icid parameter was found, then create a new, globally unique value for the 
icid parameter and insert it into the P-Charging-Vector header; and 

2) forward the request directly to the AS hosting the PSI. 

Upon successful user location query, when the response contains the URI of the assigned S-CSCF, the I-CSCF shall: 

1) insert the URI received from the HSS as the topmost Route header; 

2) store the value of the icid parameter received in the P-Charging-Vector header and retain the icid parameter in 
the P-Charging- Vector header. If no icid parameter was found, then create a new, globally unique value for the 
icid parameter and insert it into the P-Charging-Vector header. The I-CSCF shall add a type 3 orig-ioi parameter 
before the received orig-ioi parameter. The I-CSCF shall set the type 3 orig-ioi parameter to a value that 
identifies the sending network of the request. The I-CSCF shall not include the type 3 term-ioi parameter; 

3) optionally, include the received Redirect-Host AVP value in the P-User-Database header as defined in 
RFC 4457 [82]; and 
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4) forward the request based on the topmost Route header. 

NOTE 6: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

Upon successful user location query, when the response contains information about the required S-CSCF capabilities, 
the I-CSCF shall: 

1) select a S-CSCF according to the method described in 3GPP TS 29.228 [14]; 

2) insert the URI of the selected S-CSCF as the topmost Route header field value; 

3) execute the procedure described in step 2 and 3 in the above paragraph (upon successful user location query, 
when the response contains the URI of the assigned S-CSCF); 

4) optionally, include the received Redirect-Host AVP value in the P-User-Database header as defined in 

RFC 4457 [82]; 

5) if the Wildcarded PSI value is received from the HSS in the Wildcarded-PSI AVP and the I-CSCF supports the 
the SIP P-Profile-Key private header extension, include the wildcarded PSI value in the P-Profile-Key header as 
defined in draft-camarillo-sipping-profile-key [97]; and 

6) forward the request to the selected S-CSCF. 

NOTE 7: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, the I- 
CSCF shall return an appropriate unsuccessful SIP response. This response may be a 404 (Not found) or 604 (Does not 
exist anywhere) in the case the user is not a user of the home network. 

Upon an unsuccessful user location query when the response from the HSS indicates that the user is not registered and 
no services are provided for such a user, the I-CSCF shall return an appropriate unsuccessful SIP response. This 
response may be a 480 (Temporarily unavailable) response if the user is recognized as a valid user, but is not registered 
at the moment and it does not have services for unregistered users. 

When the I-CSCF receives an initial request for a dialog or standalone transaction, that contains a single Route header 
pointing to itself, the I-CSCF shall determine from the entry in the Route header whether it needs to do HSS query. In 
case HSS query is needed, then the I-CSCF shall: 

1) remove its own SIP URI from the topmost Route header; and 

2) route the request based on the Request-URJ header field. 

When the I-CSCF receives an initial request for a dialog or standalone transaction containing more than one Route 
header, the I-CSCF shall: 

1) remove its own SIP URI from the topmost Route header;and 

2) forward the request based on the topmost Route header. 

NOTE 8: In accordance with SIP the I-CSCF can add its own routeable SIP URI to the top of the Record-Route 
header to any request, independently of whether it is an initial request. The P-CSCF will ignore any 
Record-Route header that is not in the initial request of a dialog. 

When the I-CSCF receives a response to an initial request (e.g. 183 (Session Progress) response or 2xx response), the I- 
CSCF shall store the values from the P-Charging-Function- Addresses header, if present. If the next hop is outside of the 
current network, then the I-CSCF shall remove the P-Charging-Function- Addresses header prior to forwarding the 

message. 

When the I-CSCF, upon sending an initial INVITE request to the S-CSCF, receives a 305 (Use Proxy) response from 
the S-CSCF, it shall forward the initial INVITE request to the SIP URI indicated in the Contact field of the 305 (Use 
Proxy) response, as specified in RFC 3261 [26]. 
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5.3.2.1 A Originating procedures for requests containing the "orig" parameter 

The procedures of this subclause apply for requests received at the I-CSCF when the topmost Route header of the 
request contains the "orig" parameter. 

The I-CSCF shall verify for all requests whether they arrived from a trusted domain or not. If the request arrived from a 
non trusted domain, then the I-CSCF shall respond with 403 (Forbidden) response. 

If the request arrived from a trusted domain, the I-CSCF shall perform the procedures below. 

NOTE 1 : The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures 
described in 3GPP TS 33.210 [19A]. 

When the I-CSCF receives an initial request for a dialog or standalone transaction the I-CSCF will start the user 
location query procedure to the HSS as specified in 3GPP TS 29.228 [14] for the calling user, indicated in the P- 
Asserted-Identity header. Prior to performing the user location query procedure to the HSS, the I-CSCF decides which 
HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPPTS 29.228 [14]. 

When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid 
hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE 2: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When the response for user location query contains information about the required S-CSCF capabilities, the I-CSCF 
shall select a S-CSCF according to the method described in 3GPP TS 29.228 [14]. 

If the user location query was successful, the I-CSCF shall: 

1) insert the URI of the S-CSCF - either received from the HSS, or selected by the I-CSCF based on capabilities - 
as the topmost Route header appending the "orig" parameter to the URI of the S-CSCF; 

2) store the value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in 
the P-Charging-Vector header. If no icid parameter was found, then create a new, globally unique value for the 
icid parameter and insert it into the P-Charging-Vector header; 

3) optionally, include the received Redirect-Host AVP value in the P-User-Database header as defined in draft- 
camarillo-sipping-user-database [82]; and 

4) forward the request based on the topmost Route header. 

NOTE 3: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

Upon an unsuccessful user location query, the I-CSCF shall return an appropriate unsuccessful SIP response. This 
response may be a 404 (Not found) response or 604 (Does not exist anywhere) response in the case the user is not a user 
of the home network. 

When the I-CSCF receives any response to the above request, and forwards it to AS, the I-CSCF shall: 

store the values from the P-Charging-Function- Addresses header, if present. If the next hop is outside of the 
current network, then the I-CSCF shall remove the P-Charging-Function-Addresses header prior to forwarding 
the message; and 

insert a P-Charging-Vector header containing the type 3 orig-ioi parameter, if received in the request, and a type 
3 term-ioi parameter in the response. The I-CSCF shall set the type 3 term-ioi parameter to a value that identifies 
the sending network of the response and the type 3 orig-ioi parameter is set to the previously received value of 
type 3 orig-ioi. 

5.3.2.2 Abnormal cases 

In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 404 (Not 
Found) response to the UE. 
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If the I-CSCF receives a negative response to the user location query, the I-CSCF shall send back a 404 (Not Found) 
response. 

If the I-CSCF receives a CANCEL request and if the I-CSCF finds an internal state indicating a pending Cx transaction 
with the HSS, the I-CSCF: 

- shall answer the CANCEL with a 200 OK; and 

shall answer the original request with a 487 Request Terminated. 

NOTE: The I-CSCF will discard any later arriving (pending) Cx answer message from the HSS. 

With the exception of 305 (Use Proxy) rersponses, the I-CSCF may recurse on a 3xx response only when the domain 
part of the URI contained in the 3xx response is in the same domain as the I-CSCF. For the same cases, if the URI is an 
IP address, the I-CSCF shall only recurse if the IP address is known locally to be a address that represents the same 
domain as the I-CSCF. 

5.3.3 Void 

5.3.3.1 Void 

5.3.3.2 Void 

5.3.3.3 Void 

5.3.4 Void 

5.4 Procedures at the S-CSCF 
5.4.1 Registration and autlientication 
5.4.1.1 Introduction 

The S-CSCF shall act as the SIP registrar for all UAs belonging to the IM CN subsystem and with public user identities. 

Subclause 5.4. L2 through subclause 5.4. L7 define S-CSCF procedures for SIP registration that do not relate to 
emergency. All registration requests are first screened according to the procedures of subclause 5.4.8.2 to see if they do 
relate to an emergency public user identity. 

The S-CSCF shall support the use of the Path and Service-Route header. The S-CSCF shall also support the Require 
and Supported headers. The Path header is only applicable to the REGISTER request and its 200 (OK) response. The 
Service-Route header is only applicable to the 200 (OK) response of REGISTER. The S-CSCF shall not act as a 
redirect server for REGISTER requests. 

The network operator defines minimum and maximum times for each registration. These values are provided within the 
S-CSCF. 

The procedures for notification concerning automatically registered public user identities of a user are described in 

subclause 5.4.2. L2. 

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT, the S- 
CSCF may need to modify the SIP signalling according to the procedures described in annex K if both a reg-id and 
instance ID parameter are present in the received contact header as described in draft-ieft-outbound [92]. 
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5.4.1 .2 Initial registration and user-initiated reregistration 

5.4.1.2.1 Unprotected REGISTER 

NOTE 1 : Any REGISTER request sent unprotected by the UE is considered to be an initial registration. A 200 
(OK) final response to such a request will only be sent back after the S-CSCF receives a correct 
authentication challenge response in a REGISTER request that is sent integrity protected. 

NOTE 2: A REGISTER with Expires header value equal to zero should always be received protected. However, it 
is possible that in error conditions a REGISTER with Expires header value equal to zero may be received 
unprotected. In that instance the procedures below will be applied. 

Upon receipt of a REGISTER request without an "integrity-protected" parameter, or with the "integrity-protected" 
parameter in the Authorization header set to "no", for a user identity linked to a private user identity that has a registered 
public user identity but with a new contact address, the S-CSCF shall: 

1) perform the procedure for receipt of a REGISTER request without an "integrity-protected" parameter, or with 
the "integrity-protected" parameter in the Authorization header set to "no"', for the received public user identity; 
and 

2) if the authentication has been successful and if the previous registration has not expired, the S-CSCF shall 
perform the network initiated deregistration procedure only for the previous contact information as described in 

subclause 5.4.1.5. 

When S-CSCF receives a REGISTER request with the "integrity-protected" parameter in the Authorization header set 
to "no" and a non-empty response directive, the S-CSCF shall ignore the value of the response directive. 

Upon receipt of a REGISTER request without an "integrity-protected" parameter, or with the "integrity-protected" 
parameter in the Authorization header set to "no", which is not for an already registered public user identity linked to 
the same private user identity, the S-CSCF shall: 

1) identify the user by the public user identity as received in the To header and the private user identity as received 
in the username field in the Authorization header of the REGISTER request; 

2) check if the P-Visited-Network header is included in the REGISTER request, and if it is included identify the 
visited network by the value of this header; 

3) select an authentication vector for the user. If no authentication vector for this user is available, after the S-CSCF 
has performed the Cx Multimedia Authentication procedure with the HSS, as described in 3GPP TS 29.228 [14], 
the S-CSCF shall select an authentication vector as described in 3GPP TS 33.203 [19]. 

Prior to performing Cx Multimedia Authentication procedure with the HSS, the S-CSCF decides which HSS to 
query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPP TS 29.228 [14] or use the value as received in the P-User-Database header in the REGISTER request as 
defined in RFC 4457 [82]; 

NOTE 3: The HSS address received in the response to SLF query or as a value of P-User-Database header can be 
used to address the HSS of the public user identity in further queries. 

NOTE 4: At this point the S-CSCF informs the HSS, that the user currently registering will be served by the S- 

CSCF by passing its SIP URI to the HSS. This will be used by the HSS to direct all subsequent incoming 
initial requests for a dialog or standalone transactions destined for this user to this S-CSCF. 

NOTE 5: When passing its SIP URI to the HSS, the S-CSCF may include in its SIP URI the transport protocol and 
the port number where it wants to be contacted. 

4) store the icid parameter received in the P-Charging-Vector header; 

5) challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request, including a 
WWW- Authenticate header which transports: 

a globally unique name of the S-CSCF in the realm field; 

the RAND and AUTN parameters and optional server specific data for the UE in the nonce field; 
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the security mechanism, which is AKAvl-MD5, in the algorithm field; 

the IK (Integrity Key) parameter for the P-CSCF in the ik field (see subclause 7.2A. 1); and 

the CK (Cipher Key) parameter for the P-CSCF in the ck field (see subclause 7.2A.1); 

6) store the RAND parameter used in the 401 (Unathorized) response for future use in case of a resynchronisation. 
If a stored RAND already exists in the S-CSCF, the S-CSCF shall overwrite the stored RAND with the RAND 
used in the most recent 401 (Unauthorized) response; 

7) send the so generated 401 (Unauthorized) response towards the UE; and, 

8) start timer reg-await-auth which guards the receipt of the next REGISTER request. 

If the received REGISTER request indicates that the challenge sent previously by the S-CSCF to the UE was deemed to 
be invalid by the UE, the S-CSCF shall stop the timer reg-await-auth and proceed as described in the 
subclause 5.4.1.2.3. 

5.4.1.2.2 Protected REGISTER 

Upon receipt of a REGISTER request with the "integrity-protected" parameter in the Authorization header set to "yes", 
the S-CSCF shall identify the user by the public user identity as received in the To header and the private user identity 
as received in the Authorization header of the REGISTER request, and: 

In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is running): 

1) check if the user needs to be reauthenticated. 

The S-CSCF may require authentication of the user for any REGISTER request, and shall always require 
authentication for REGISTER requests received without the "integrity-protected" parameter in the Authorization 
header set to "yes". 

If the user needs to be reauthenticated, the S-CSCF shall proceed with the procedures as described for the initial 
REGISTER in subclause 5.4.1.2.1, beginning with step 4). If the user does not need to be reauthenticated, the S- 
CSCF shall proceed with the following steps in this paragraph; and 

2) check whether an Expires timer is included in the REGISTER request and its value. If the Expires header 
indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in subclause 5.4.1.4. 
If the Expires header does not indicate zero, the S-CSCF shall check whether the public user identity received in 
the To header is already registered. If it is not registered, the S-CSCF shall proceed beginning with step 5 below. 
Otherwise, the S-CSCF shall proceed beginning with step 6 below. 

In the case that a timer reg-await-auth is running for this user the S-CSCF shall: 

1) check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried 
the last challenge. The S-CSCF shall only proceed further if the Call-IDs match. 

2) stop timer reg-await-auth; 

3) check whether an Authorization header is included, containing: 

a) the private user identity of the user in the username field; 

b) the algorithm which is AKAvl-MD5 in the algorithm field; and 

c) the authentication challenge response needed for the authentication procedure in the response field. 

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge 
response was included; 

4) check whether the received authentication challenge response and the expected authentication challenge 
response (calculated by the S-CSCF using XRES and other parameters as described in RFC 3310 [49]) match. 
The XRES parameter was received from the HSS as part of the Authentication Vector. The S-CSCF shall only 
proceed with the following steps if the challenge response received from the UE and the expected response 
calculated by the S-CSCF match; 
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5) after performing the Cx Server Assignment procedure with the HSS, as described in 3GPP TS 29.228 [14], store 
the following information in the local data: 

a) the list of public user identities, including the registered own public user identity and its associated set of 
implicitly registered public user identities due to the received REGISTER request. Each public user identity 
is identified as either barred or non-barred; and, 

b) all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), 
including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the 
unregisterd part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes 
unregistered); 

NOTE 1 : There might be more than one set of initial Filter Criteria received because some implicitly registered 

public user identities that are part of the same implicit registration set belong to different service profiles. 

6) update registration bindings: 

a) bind to each non-barred registered public user identity all registered contact information including all header 
parameters contained in the Contact header and all associated URl parameters, with the exception of the URI 
"pub-gruu" and "temp-gruu" parameters as specified in draft-ietf-sip-gruu [93], and store information for 
future use; 

b) for each binding that contains a H-sip. instance header parameter, assign a new temporary GRUU, as specified 
in subclause 5.4.7A.3. 

NOTE 2: There might be more then one contact information available for one public user identity. 

NOTE 3: The barred public user identities are not bound to the contact information. 

7) check whether a Path header was included in the REGISTER request and construct a list of preloaded Route 
headers from the list of entries in the received Path header. The S-CSCF shall preserve the order of the preloaded 
Route headers and bind them to the contact information that was received in the REGISTER message; 

NOTE 4: If this registration is a reregistration or an initial registration (i.e., there are previously registered public 
user identities belonging to the user that have not been deregistered or expired), then a list of pre-loaded 
Route headers will already exist. The new list replaces the old list. 

8) determine the duration of the registration by checking the value of the Expires header in the received REGISTER 
request. The S-CSCF may reduce the duration of the registration due to local policy or send back a 423 (Interval 
Too Brief) response specifying the minimum allowed time for registration; 

9) store the icid parameter received in the P-Charging- Vector header; 

10) if an orig-ioi parameter is received in the P-Charging- Vector header, store the value of the received orig-ioi 
parameter; 

NOTE 5: Any received orig-ioi parameter will be a type 1 orig-ioi. The type 1 orig-ioi identifies the network from 
which the request was sent. 

1 1) create a 200 (OK) response for the REGISTER request, including: 

a) the list of received Path headers; 

b) a P-Associated-URI header containing the list of the registered public user identity and its associated set of 
implicitly registered public user identities. The first URI in the list of public user identities supplied by the 
HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user 
identity indicated as the default public user identity must be a registered public user identity. The S-CSCF 
shall place the default public user identity as the first entry in the list of URIs present in the P-Associated- 
URI header. The default public user identity will be used by the P-CSCF in conjunction with the procedures 
for the P-Asserted-Identity header, as described in subclause 5.2.6.3. If the S-CSCF received a display name 
from the HSS for a public user identity, then it shall populate the P-Associated-URI header entry for that 
public identity with the associated display name. The S-CSCF shall not add a barred public user identity to 
the list of URIs in the P-Associated-URI header; 
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NOTE 6: The P-Associated-URI header lists only the public user identity and its associated set of implicitly 

registered public user identities that have been registered, rather than the list of user's URIs that may be 
either registered or unregistered as specified in the RFC 3455 [52]. If the registered public user identity 
which is not barred does not have any other associated public user identities, the P-Associated-URI 
header lists only the registered public user identity itself, rather than an empty P-Associated-URI header 
as specified in RFC 3455 [52]. 

c) a Service-Route header containing: 

the SIP URI identifying the S-CSCF containing an indication that requests routed via the service route 
(i.e. from the P-CSCF to the S-CSCF) are treated as for the UE-originating case. This indication may e.g. 
be in a URI parameter, a character string in the user part of the URI or be a port number in the URI; and, 

if network topology hiding is required a SIP URI identifying an IBCF as the topmost entry; 

d) a P-Charging-Function-Addresses header containing the values received from the HSS if the P-CSCF is in 
the same network as the S-CSCF. It can be determined if the P-CSCF is in the same network as the S-CSCF 
by the contents of the P-Visited-Network-ID header field included in the REGISTER request; 

e) a P-Charging-Vector header containing the orig-ioi parameter, if received in the REGISTER request and a 
type I term-ioi parameter. The S-CSCF shall set the type I term-ioi parameter to a value that identifies the 
sending network of the response and the orig-ioi parameter is set to the previously received value of orig-ioi; 

f) a Contact header listing all contact addresses for this public user identity, including all saved header and URI 
parameters, and 

g) gruus in the Contact header. If the REGISTER request contained a Required or Supported header containing 
the value "gruu" then for each contact address in the contact header that has a H-sip. instance header parameter, 
add "pub-gruu" and "temp-gruu" header parameters. The values of these parameters shall contain, 
respectively, the public GRUU and the most recently assigned temporary GRUU representing (as specified in 
subclause 5.4. 7A) the association between the public user identity from the To header in the REGISTER 
request and the instance ID contained in the H-sip. instance parameter. 

NOTE 7: There might be other contact addresses available, that other UEs have registered for the same public user 
identity. 

12) send the so created 200 (OK) response to the UE; 

13) for all service profiles in the implicit registration set send a third-party REGISTER request, as described in 
subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the 
REGISTER event; and, 

NOTE 8: If this registration is a reregistration, the Filter Criteria already exists in the local data. 

NOTE 9: If the same AS matches the Filter Criteria of several service profiles for the event of REGISTER request, 
then the AS will receive several third-party REGISTER requests. Each of these requests will include a 
public user identity from the corresponding service profile. 

14) handle the user as registered for the duration indicated in the Expires header. 

5.4.1.2.3 Abnormal cases 

In the case that the REGISTER request, that contains the authentication challenge response from the UE does not match 
with the expected REGISTER request (e.g. wrong Call-Id or authentication challenge response) and the request has the 
"integrity-protected" parameter in the Authorization header set to "yes", the S-CSCF shall: 

send a 403 (Forbidden) response to the UE. The S-CSCF shall consider this authentication attempt as failed. The 
S-CSCF shall not update the registration state of the subscriber. 

NOTE 1: If the UE was registered before, it stays registered until the registration expiration time expires. 

In the case that the REGISTER request, which was supposed to carry the response to the challenge, contains no 
authentication challenge response and no AUTS parameters indicating that the MAC parameter was invalid in the 
challenge, the S-CSCF shall: 
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respond with a 403 (Forbidden) response to the UE. The S-CSCF shall not update the registration state of the 
subscriber. 

NOTE 2: If the UE was registered before, it stays registered until the registration expiration time expires. 

In the case that the REGISTER request from the UE containing an AUTS directive, indicating that the SQN was 
deemed to be out of range by the UE), the S-CSCF will fetch new authentication vectors from the HSS. In order to 
indicate a resynchronisation, the S-CSCF shall include the AUTS directive received from the UE and the stored RAND, 
when fetching the new authentication vectors. On receipt of the new authentication vectors from the HSS, the S-CSCF 
shall either: 

send a 401 (Unauthorized) response to initiate a further authentication attempt, using these new vectors; or 

respond with a 403 (Forbidden) response if the authentication attempt is to be abandoned. The S-CSCF shall not 
update the registration state of the subscriber. 

NOTE 3: If the UE was registered before, it stays registered until the registration expiration time expires. 

NOTE 4: Since the UE responds only to two consecutive invalid challenges, the S-CSCF will send a 401 
(Unauthorized) response that contains a new challenge only twice. 

NOTE 5: In the case of an AUTS directive being present in the REGISTER request, the response directive in the 
same REGISTER request will not be taken into account by the S-CSCF. 

In the case that the expiration timer from the UE is too short to be accepted by the S-CSCF, the S-CSCF shall: 

reject the REGISTER request with a 423 (Interval Too Brief) response, containing a Min-Expires header with 
the minimum registration time the S-CSCF will accept. 

On receiving a failure response to one of the third-party REGISTER requests, based on the information in the Filter 
Criteria the S-CSCF may: 

abort sending third-party REGISTER requests; and 

initiate network-initiated deregistration procedure. 

If the Filter Criteria does not contain instruction to the S-CSCF regarding the failure of the contact to the AS, the S- 
CSCF shall not initiate network-initiated deregistration procedure. 

In the case that the REGISTER request from the UE contains more than one SIP URIs as Contact header entries, the S- 
CSCF shall store: 

the entry in the Contact header with the highest "q"; or 

an entry decided by the S-CSCF based on local policy; 

and include it in the 200 (OK) response. 

NOTE 6: If the timer reg-await-auth expires, the S-CSCF will consider the authentication to have failed. If the 
public user identity was already registered, the S-CSCF will leave it registered, as described in 
3GPPTS 33.203 [19]. 

In the case that the S-CSCF receives a REGISTER request with the "integrity-protected" parameter in the Authorization 
header set to "yes", for which the public user identity received in the To header and the private user identity received in 
the Authorization header of the REGISTER request do not match to any registered user at this S-CSCF, the S-CSCF 
shall: 

respond with a 500 (Server Internal Error) response to the UE. 

NOTE 7: This error is not raised if there is a match on the private user identity, but no match on the public user 
identity. 

For any error response, the S-CSCF shall insert a P-Charging- Vector header containing the orig-ioi parameter, if 
received in the REGISTER request and a type 1 term-ioi parameter. The S-CSCF shall set the type 1 term-ioi parameter 
to a value that identifies the sending network of the response and the orig-ioi parameter is set to the previously received 
value of orig-ioi. 
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NOTE 8: Any previously received orig-ioi parameter will be a type 1 orig-ioi. The type 1 orig-ioi identifies the 
visited network of the registered user. 

5.4.1 .3 Authentication and reauthentication 

Authentication and reauthentication is performed by the registration procedures as described in subclause 5.4.1.2. 

5.4.1 .4 User-initiated deregistration 

When S-CSCF receives a REGISTER request with the Expires header field containing the value zero, the S-CSCF 
shall: 

check whether the "integrity-protected" parameter in the Authorization header field set to "yes", indicating that 
the REGISTER request was received integrity protected. The S-CSCF shall only proceed with the following 
steps if the "integrity-protected" parameter is set to "yes"; 

release each multimedia session that includes this user, where the session was initiated by this UE with the 
public user identity found in the P-Asserted-Identity header field or with one of the implicitly registered public 
user identities by applying the steps listed in subclause 5.4.5.1.2; 

if this public user identity was registered only by this UE, deregister the public user identity found in the To 
header field together with the implicitly registered public user identities. Otherwise, the S-CSCF will only 
remove the contact address that was registered by this UE; 

for all service profiles in the implicit registration set send a third-party REGISTER request, as described in 
subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the 
REGISTER event; and 

if this is a deregistration request for the only public user identity currently registered with its associated set of 
implicitly registered public user identities (i.e. no other is registered) and there are still active multimedia 
sessions that includes this user, where the session was initiated with the public user identity currently registered 
or with one of the implicitly registered public user identities, release each of these multimedia sessions by 
applying the steps listed in subclause 5.4.5.1.2. 

If all public user identities of the UE are deregistered, then the S-CSCF may consider the UE and P-CSCF subscriptions 
to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header containing 
a value of zero). 

If the Authorization header of the REGISTER request did not contain an "integrity-protected" parameter, or the 
"integrity-protected" parameter was set to the value "no", the S-CSCF shall apply the procedures described in subclause 
5.4.1.2.1. 

On completion of the above procedures in this subclause and of the Cx Server Assignment procedure with the HSS, as 
described in 3GPP TS 29.228 [14], for one or more public user identities, the S-CSCF shall update or remove those 
public user identities, their registration state and the associated service profiles from the local data (based on operators' 
policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF allocated to this subscriber). 

5.4.1 .5 Network-initiated deregistration 

NOTE 1: A network-initiated deregistration event that occurs at the S-CSCF may be received from the HSS or may 
be an internal event in the S-CSCF. 

Prior to initiating the network-initiated deregistration for the only currently registered public user identity and its 
associated set of implicitly registered public user identities that have been registered with the same contact (i.e. no other 
public user identity is registered with this contact) while there are still active multimedia sessions belonging to this 
contact, the S-CSCF shall release only the multimedia sessions belonging to this contact as described in the following 
paragraph. The multimedia sessions for the same public user identity, if registered with another contact remain 
unchanged. 

Prior to initiating the network-initiated deregistration while there are still active multimedia sessions that are associated 
with this user and contact, the S-CSCF shall release none, some or all of these multimedia sessions by applying the 
steps listed in subclause 5.4.5.1.2 under the following conditions: 
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when the S-CSCF does not expect the UE to reregister (i.e. S-CSCF will set the event attribute within the 
<contact> element to "rejected" for the NOTIFY request, as described below), the S-CSCF shall release all 
sessions that are associated with the public user identities being deregistered, which includes the implicitly 
registered public user identities. 

when the S-CSCF expects the UE to reregister (i.e. S-CSCF will set the event attribute within the <contact> 
element to "deactivated" for the NOTIFY request, as described below), the S-CSCF shall only release sessions 
that currently include the user, where the session was initiated with the one of the public user identities being 
deregistered, which includes the implicitly registered public user identities. 

When a network-initiated deregistration event occurs for one or more public user identities that are bound to one or 
more contacts, the S-CSCF shall send a NOTIFY request to all subscribers that have subscribed to the respective reg 
event package. For each NOTIFY request, the S-CSCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the 
S-CSCF is aware of the user owns; 

4) set the aor attribute within each <registration> element to one public user identity: 

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact 
address provided by the UE; 

b) if the public user identity: 

i) has been deregistered then: 

set the state attribute within the <registration> element to "terminated"; 

set the state attribute within the <contact> element to "terminated"; and 

set the event attribute within the <contact> element to "deactivated" if the S-CSCF expects the UE to 
reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or 

ii) has been kept registered then: 

I) set the state attribute within the <registration> element to "active"; 

II) set the state attribute within the <contact> element to: 

for the contact address to be removed set the state attribute within the <contact> element to 
"terminated", and event attribute element to "deactivated" if the S-CSCF expects the UE to 
reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or 

for the contact address which remain unchanged, if any, leave the <contact> element unmodified, 
and if the contact has been assigned GRUUs set the <pub-gruu> and <temp-gruu> sub-elements of 
the <contact> element as specified in draft-ietf-sipping-gruu-reg-event [94] and include the 
<unknown-param> sub-element within each <contact> to any additional header parameters 
contained in the Contact header of the REGISTER request according to RFC 3680 [43]; and 

NOTE 2: There might be more than one contact information available for one public user identity. When 
deregistering this UE, the S-CSCF will only modify the <contact> elements that were originally 
registered by this UE using its private user identity. The <contact> elements of the same public user 
identitity, if registered by another UE using different private user identities remain unchanged. 

5) add a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]. 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" 
(i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the 
registration event package by setting the Subscription-State header to the value of "terminated". 
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Also, for all service profiles in the implicit registration set the S-CSCF shall send a third-party REGISTER request, as 
described in subclause 5.4. 1 .7, to each AS that matches the Filter Criteria of the service profile from the HSS as if a 
equivalent REGISTER request had been received from the user deregistering that public user identity, or combination 
of public user identities. 

In case of the deregistration of the old contact information when the UE is roaming, registration is done in a new 
network and the previous registration has not expired, on completion of the above procedures, the S-CSCF shall remove 
the registration information related to the old contact from the local data. 

Otherwise, on completion of the above procedures for one or more public user identities linked to the same private user 
identity, the S-CSCF shall deregister those public user identities and the associated implicitly registered public user 
identities. On completion of the Cx Server Assignment procedure with the HSS, as described in 3GPP TS 29.228 [14], 
the S-CSCF shall update or remove those public user identities linked to the same private user identity, their registration 
state and the associated service profiles from the local data (based on operators' policy the S-CSCF can request of the 
HSS to either be kept or cleared as the S-CSCF allocated to this subscriber). On the completion of the Cx Registration- 
Termination procedure with the HSS, as described in 3GPP TS 29.228 [14], the S-CSCF shall remove those public user 
identities, their registration state and the associated service profiles from the local data. 

5.4.1.6 Network-initiated reauthentication 

The S-CSCF may request a subscriber to reauthenticate at any time, based on a number of possible operator settable 
triggers as described in subclause 5.4.1.2. 

If the S-CSCF is informed that a private user identity needs to be re-authenticated, the S-CSCF shall generate a 
NOTIFY request on all dialogs which have been established due to subscription to the reg event package of that user. 
For each NOTIFY request the S-CSCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the 
S-CSCF is aware of the user owns: 

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact 
address provided by the UE; 

b) set the aor attribute within each <registration> element to one public user identity; 

c) set the state attribute within each <registration> element to "active"; 

d) set the state attribute within each <contact> element to "active"; 

e) set the event attribute within each <contact> element that was registered by this UE to "shortened"; 

f) set the expiry attribute within each <contact> element that was registered by this UE to an operator defined 
value; and 

g) set the <pub-gruu> and <temp-gruu> sub-elements within each <contact> element as specified in 
subclause 5.4.2.1.2; and 

NOTE 1: There might be more than one contact information available for one public user identity. The S-CSCF 
will only modify the <contact> elements that were originally registered by this UE using its private user 
identity. The S-CSCF will not modify the <contact> elements for the same public user identitity, if 
registered by another UE using different private user identity. 

4) set a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]. 
Afterwards the S-CSCF shall wait for the user to reauthenticate (see subclause 5.4.1.2). 

NOTE 2: Network initiated re-authentication may occur due to internal processing within the S-CSCF. 
The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 
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When generating the NOTIFY request, the S-CSCF shall shorten the validity of all registration lifetimes associated with 
this private user identity to an operator defined value that will allow the user to be re-authenticated. 

5.4.1 .7 Notification of Application Servers about registration status 

During registration, the S-CSCF shall include a P- Access-Network-Info header and a P-Visited-Network-ID header (as 
received in the REGISTER request from the UE) in the 3rd-party REGISTER sent towards the ASs, if the AS is part of 
the trust domain. If the AS is not part of the trust domain, the S-CSCF shall not include any P-Access-Network-Info 
header or P-Visited-Network-ID header. The S-CSCF shall not include a P-Access-Network-Info header in any 
responses to the REGISTER request. 

If the registration procedure described in subclauses 5.4.1.2, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful, the S- 
CSCF shall send a third-party REGISTER request to each AS with the following information: 

a) the Request-URI, which shall contain the AS's SIP URI; 

b) the From header, which shall contain the S-CSCF's SIP URI; 

c) the To header, which shall contain a non-barred public user identity belonging to the service profile of the 
processed Filter Criteria. It may be either a public user identity as contained in the REGISTER request received 
from the UE or one of the implicitly registered public user identities in the service profile, as configured by the 
operator; 

NOTE 1 : For the whole implicit registration set only one public user identity per service profile appears in the 

third-party REGISTER requests. Thus, based on third-party REGISTER requests only, the ASs will not 
have complete information on the registration state of each public user identity in the implicit registration 
set. The only way to have a complete and continuously updated information (even upon administrative 
change in subscriber's profile) is to subscribe to the reg event package. 

d) the Contact header, which shall contain the S-CSCF's SIP URI; 

e) for initial registration and user-initiated reregistration (subclause 5.4.1.2), the Expires header, which shall 
contain the same value that the S-CSCF returned in the 200 (OK) response for the REGISTER request received 
from the UE; 

f) for user-initiated deregistration (subclause 5.4.1.4) and network-initiated deregistration (subclause 5.4.1.5), the 
Expires header, which shall contain the value zero; 

g) for initial registration and user-initiated reregistration (subclause 5.4.1.2), a message body, if there is Filter 
Criteria indicating the need to include HSS provided data for the REGISTER event (e.g. HSS may provide AS 
specific data to be included in the third-party REGISTER). If there is a service information XML element 
provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then the S-CSCF shall include it in the 
message body of the REGISTER request within the <service-info> XML element as described in subclause 7.6. 
For the messages including the IM CN subsystem XML body, the S-CSCF shall set the value of the Content- 
Type header to include the MIME type specified in subclause 7.6; 

h) for initial registration and user-initiated reregistration, the P-Charging-Vector header, which shall contain the 
same icid parameter that the S-CSCF received in the original REGISTER request from the UE and add a type 3 
orig-ioi parameter before the received orig-ioi parameter. The S-CSCF shall set the type 3 orig-ioi parameter to 
a value that identifies the sending network of the request. The S-CSCF shall not include the type 3 term-ioi 
parameter; and 

i) for initial registration and user-initiated reregistration, a P-Charging-Function- Addresses header, which shall 
contain the values received from the HSS if the message is forwarded within the S-CSCF home network. 

When the S-CSCF receives any response to a third-party REGISTER request, the S-CSCF shall store the value of the 
term-ioi parameter received in the P-Charging-Vector header, if present. 

NOTE 2: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the service 
provider from which the response was sent. 

If the S-CSCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response to a third- 
party REGISTER, the S-CSCF shall: 
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- if the default handling defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 
3GPP TS 29.228 [14] or no default handling is indicated, no further action is needed; and 

if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified 
in 3GPP TS 29.228 [14], the S-CSCF shall, for a currently registered public user identity, initiate the network- 
initiated deregistration as described in subclause 5.4.1.5. 

5.4.1 .8 Service profile updates 

NOTE 1: The S-CSCF can receive an update of subscriber data notification on the Cx interface, from the HSS, 
which can affect the stored information about served public user identities. According to 
3GPP TS 29.228 [14], the changes are guaranteed not to affect the default public user identity within the 
registration implicit set. 

When receiving a Push-Profile-Request (PPR) from the HSS (as described in 3GPP TS 29.228 [14]), modifying the 
service profile of served public user identities, the S-CSCF shall synchronize with the UE and IM CN entities, by either: 

performing the procedures for notification of the reg-event subscribers about registration state, as described in 
subclause 5.4.2.1.2; or 

triggering the UE to re-register, by shortening the life time of the current registration, as described in 
subclause 5.4.1.6. 

If the modification of the service profile consists in the addition of a new non-barred public user identity to an implicit 
set, or in the change of status from barred to non-barred for a public user identity already in the implicit set, the S-CSCF 
shall add the public user identity to the list of registered, non-barred public user identities. 

If the modification of the service profile consists in the deletion or in the change of status from non-barred to barred of a 
public user identity in an implicit set, the S-CSCF shall remove the public user identity from the list of registered, non- 
barred public user identities. 

NOTE 2: As the S-CSCF checks the barring status of the public user identity on receipt of a initial request for a 
dialog, or a standalone transaction, the above procedures have no impact on transactions or dialogs 
already in progress and are effective only for new transactions and dialogs. 

5.4.2 Subscription and notification 

5.4.2.1 Subscriptions to S-CSCF events 

5.4.2.1 .1 Subscription to the event providing registration state 

When an incoming SUBSCRIBE request addressed to S-CSCF arrives containing the Event header with the reg event 
package, the S-CSCF shall: 

1) check if, based on the local policy, the request was generated by a subscriber who is authorised to subscribe to 
the registration state of this particular user. The authorized subscribers include: 

all public user identities this particular user owns, that the S-CSCF is aware of, and which are not-barred; 

all the entities identified by the Path header (i.e. the P-CSCF to which this user is attached to); and 

all the ASs listed in the initial filter criteria that are part of the trust domain; and 

NOTE 1 : The S-CSCF finds the identity for authentication of the subscription in the P-Asserted-Identity header 
received in the SUBSCRIBE request. 

2) store the value of the orig-ioi parameter received in the P-Charging-Vector header if present; and 

NOTE 2: Any received orig-ioi parameter will be a type 3 orig-ioi. The type 3 orig-ioi identifies the service 
provider from which the request was sent. 

3) generate a 2xx response acknowledging the SUBSCRIBE request and indicating that the authorised subscription 
was successful as described in RFC 3680 [43]. The S-CSCF shall populate the header fields as follows: 
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an Expires header, set to either the same or a decreased value as the Expires header in SUBSCRIBE request; 
and 

if the request originated from an ASs Hsted in the initial filter criteria, a P-Charging-Vector header containing 
the orig-ioi parameter, if received in the SUBSCRIBE request, and a type 3 term-ioi. The S-CSCF shall set 
the type 3 term-ioi parameter to a value that identifies the sending network of the response and the orig-ioi 
parameter is set to the previously received value of orig-ioi. 

The S-CSCF may set the Contact header to an identifier uniquely associated to the SUBSCRIBE request and 
generated within the S-CSCF, that may help the S-CSCF to correlate refreshes for the SUBSCRIBE. 

NOTE 3: The S-CSCF could use such unique identifiers to distinguish between UEs, when two or more users, 
holding a shared subscription, register under the same public user identity. 

Afterwards the S-CSCF shall perform the procedures for notification about registration state as described in 
subclause 5.4.2.1.2. 

For any final response that is not a 2xx response, the S-CSCF shall insert a P-Charging-Vector header containing the 
orig-ioi parameter, if received in the SUBSCRIBE request and a type 3 term-ioi. The S-CSCF shall set the type 3 term- 
ioi parameter to a value that identifies the sending network of the response and the orig-ioi parameter is set to the 
previously received value of orig-ioi. 

5.4.2.1 .2 Notification about registration state 

When sending a NOTIFY request, the S-CSCF shall not use the default filtering policy as specified in RFC 3680 [43], 
i.e. the S-CSCF shall always include in every NOTIFY request the state information of all registered public user 
identities of the user (i.e. the full state information). 

When generating NOTIFY requests, the S-CSCF shall not preclude any valid reg event package parameters in 
accordance with RFC 3680 [43]. 

For each NOTIFY request on all dialogs which have been established due to subscription to the reg event package of 
that user, the S-CSCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include one <registration> elements for each public user identity that the S- 
CSCF is aware the user owns. 

If the user shares one or more public user identities with other users, any contact addresses registered by other 
users of the shared public user identity shall be included in the NOTIFY request; 

4) for each <registration> element: 

a) set the aor attribute to one public user identity; 

b) set the <uri> sub-element inside each <contact> sub-element of the <registration> element to the contact 
address provided by the respective UE as follows: 

I) if the aor attribute of the <registration> element contains a sip or sips URI, then for each contact address 
that contains a H-sip.instance header parameter, include <pub-gruu> and <temp-gruu> sub-elements within 
the corresponding <contact> element. The contents of these elements shall contain, respectively, the 
public and temporary GRUUs representing (as specified in subclause 5. 4. 7 A) the association between the 
aor attribute of the <registration> element and the instance ID contained in the H-sip.instance parameter; or 

II) if the aor attribute of the <registration> element contains a tel-URI, determine its alias SIP URI and then 
include a copy of the <pub-gruu> and <temp-gruu> sub-elements from that equivalent element; and 

c) if the public user identityset at step a): 

I) has been deregistered (i.e. no active contact left) then: 

- set the state attribute within the <registration> element to "terminated"; 
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set the state attribute within each <contact> element to "terminated"; and 

set the event attribute within each <contact> element to "deactivated", "expired", "unregistered", 
"rejected" or "probation" according to RFC 3680 [43]. 

If the public user identity has been deregistered and the deregistration has already been indicated in the 
NOTIFY request, and no new registration has occurred, its <registration> element shall not be included in 
the subsequent NOTIFY requests; or 

II) has been registered then: 

set the <unknown-param> element to any additional header parameters contained in the contact 
header of the REGISTER request according to RFC 3680 [43]; 

set the state attribute within the <registration> element to "active", if not already set to "active", 
otherwise leave it unchanged; and: 

set the state attribute within the <contact> element to "active"; and set the event attribute within the 
<contact> element to "registered"; or 

III) has been re-registered then: 

set the <unknown-param> element to any additional header parameters contained in the contact 
header of the REGISTER request according to RFC 3680 [43]; 

for contact addresses to be registered: set the state attribute within the <contact> element to "active"; 
and set the event attribute within the <contact> element to "registered"; or 

for contact addresses to be re-registered, set the state attribute within the <contact> element to 
"active"; and set the event attribute within the <contact> element to "refreshed" according to 
RFC 3680 [43]; or 

for contact addresses that remain unchanged, if any, leave the <contact> element unmodified; or 

IV)has been automatically registered, and has not been previously automatically registered: 

set the <unknown-param> element to any additional header parameters contained in the contact 
header of the originsl REGISTER request according to RFC 3680 [43]; 

set the state attribute within the <registration> element to "active"; 

set the state attribute within the <contact> element to "active"; and 

set the event attribute within the <contact> element to "created"; and 

5) set the P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17] and a 
type 3 orig-ioi parameter. The S-CSCF shall set the type 3 orig-ioi parameter to a value that identifies the 
sending network of the request. The S-CSCF shall not include the type 3 term-ioi parameter. 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

EXAMPLE: If sip: user l_publicl @homel .net is registered, the public user identity 

sip:userl_public2@ho mel.net can automatically be registered. Therefore the entries in the body of 
the NOTIFY request look like: 

<?xml version=" 1 . " ?> 

<reginf o xmlns="urn : ietf : pa rams : xml : ns : reginf o" 
version="0 " state="f ull"> 
<registration aor="sip : userl_publicl@homel . net " id="as9" 

state="active"> 
< contact id="76" st at e=" active" event=" registered" > 
<uri>sip: [5555: : aaa : bbb : ccc : ddd] </uri> 
<unknown-param name=" audio" /> 
</contact> 
</registration> 

<registration aor="sip : userl_public2@homel . net " id="aslO " 
state="active"> 
< contact id=" 86" st at e=" active" event =" created" > 
<uri>sip: [5555: : aaa : bbb : ccc : ddd] </uri> 
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<unknown-param name="audio"/> 
</contact> 
</registration> 
</reginfo> 

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" 
(i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the 
registration event package by setting the Subscription-State header to the value of "terminated". 

When all of a UE's contact addresses have been deregistered (i.e. there is no <contact> element set to "active" for this 
UE), the S-CSCF shall consider subscription to the reg event package belonging to the UE cancelled (i.e. as if the UE 
had sent a SUBSCRIBE request with an Expires header containing a value of zero). 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

When the S-CSCF receives any response to the NOTIFY request, the S-CSCF shall store the value of the term-ioi 
parameter received in the P-Charging- Vector header, if present. 

NOTE: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the service 
provider from which the response was sent. 

5.4.3 General treatment for all dialogs and standalone transactions 
excluding requests terminated by the S-CSCF 

5.4.3.1 Determination of UE-originated or UE-terminated case 

Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the S-CSCF shall: 

perform the procedures for the UE-originating case as described in subclause 5.4.3.2 if the request makes use of 
the information for UE-originating calls, which was added to the Service-Route header entry of the S-CSCF 
during registration (see subclause 5.4.1.2), e.g. the message is received at a certain port or the topmost Route 
header contains a specific user part or parameter; or, 

perform the procedures for the UE-originating case as described in subclause 5.4.3.2 if the topmost Route header 
of the request contains the "orig" parameter. The S-CSCF shall remove the "orig" parameter from the topmost 
Route header; or, 

perform the procedures for the UE-terminating case as described in subclause 5.4.3.3 if this information is not 
used by the request. 

5.4.3.2 Requests initiated by the served user 

When the S-CSCF receives from the served user or from a PSI an initial request for a dialog or a request for a 
standalone transaction, and the request is received either from a functional entity within the same trust domain or 
contains a valid original dialog identifier (see step 3) or the dialog identifier (From, To and Call-ID header fields) 
relates to an existing request processed by the S-CSCF, then prior to forwarding the request, the S-CSCF shall: 

1) determine whether the request contains a barred public user identity in the P-Asserted-Identity header field of the 
request or not. In case the said header field contains a barred public user identity for the user, then the S-CSCF 
shall reject the request by generating a 403 (Forbidden) response. Otherwise, continue with the rest of the steps; 

NOTE 1: If the P-Asserted-Identity header field contains a barred public user identity, then the message has been 
received, either directly or indirectly, from a non-compliant entity which should have had generated the 
content with a non-barred public user identity. 

1 A) if the Contact is a GRUU, but is not valid as defined in subclause 5.4.7A.4, then return a 4xx response as 
specified in draft-ietf-sip-gruu [93]; 

2) store the value of the orig-ioi parameter received in the P-Charging-Vector header if present, and remove it from 
any forwarded request; 

NOTE 2: Any received orig-ioi parameter will be a type 3 orig-ioi. The type 3 orig-ioi identifies the service 
provider from which the request was sent (AS initiating a session on behalf of a user or a PSI); 
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3) check if an original dialog identifier that the S-CSCF previously placed in a Route header is present in the 
topmost Route header of the incoming request. If present, the request has been sent from an AS in response to a 
previously sent request; 

4) remove its own SIP URI from the topmost Route header; 

5) check whether the initial request matches the next unexecuted initial filter criteria based on a public user identity 
in the P-Asserted-Identity header in the priority order as described in 3GPP TS 23.218 [5], and if it does, the S- 
CSCF shall: 

a) insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI 
populated as specified in the subclause 5.4.3.4; 

b) if the AS is located outside the trust domain then the S-CSCF shall remove the P-Access-Network-Info 
header field and its values in the request and the access-network-charging-info parameter in the P-Charging- 
Vector header from the request that is forwarded to the AS; if the AS is located within the trust domain, then 
the S-CSCF shall retain the P-Access-Network-Info header field and its values and the access-network- 
charging-info parameter in the P-Charging-Vector header in the request that is forwarded to the AS; and 

c) insert a type 3 orig-ioi parameter before the received orig-ioi parameters in the P-Charging-Vector header. 
The S-CSCF shall set the type 3 orig-ioi parameter to a value that identifies the sending network of the 
request. The S-CSCF shall not include the type 3 term-ioi parameter; 

NOTE 3: Depending on the result of processing the filter criteria the S-CSCF might contact one or more AS(s) 
before processing the outgoing Request-URL 

6) if there is no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the icid parameter received in the P-Charging-Vector header and retain the icid parameter in the P- 
Charging -Vector header. Optionally, the S-CSCF may generate a new, globally unique icid and insert the new 
value in the icid parameter of the P-Charging-Vector header when forwarding the message. If the S-CSCF 
creates a new icid, then it is responsible for maintaining the two icid values in the subsequent messaging; 

7) in step 5, if the initial request did not match the next unexecuted initial filter criteria (i.e. the request is not 
forwarded to an AS), insert an orig-ioi parameter into the P-Charging-Vector header. The S-CSCF shall set the 
type 2 orig-ioi parameter to a value that identifies the sending network. The S-CSCF shall not include the type 2 
term-ioi parameter; 

8) if there is no original dialog identifier present in the topmost Route header of the incoming request insert a P- 
Charging-Function- Addresses header populated with values received from the HSS if the message is forwarded 
within the S-CSCF home network, including towards AS; 

9) if there is no original dialog identifier present in the topmost Route header of the incoming request and if the S- 
CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity header is an alias SIP URI 
for a tel URI, add a second P-Asserted-Identity header containing this tel-URI, including the display name 
associated with the tel URI, if available. If the P-Asserted-Identity header contains only a tel URI, the S-CSCF 
shall add a second P-Asserted-Identity header containing a SIP URI. The added SIP URI shall contain in the user 
part a "+" followed by the international public telecommunication number contained in tel URI, and user's home 
domain name in the hostport part. The added SIP URI shall contain the same value in the display name as 
contained in the tel URI. The S-CSCF shall also add a user parameter equals "phone" to the SIP URI; 

NOTE 4: The S-CSCF recognizes that a given SIP URI is an alias SIP URI of a tel URI, since they have the same 
service profile and belong to the same set of implicitly registered public user identities. If tel URI is 
shared URI so is the alias SIP URI. 

10) if the request is not forwarded to an AS and if the outgoing Request-URI is: 

- a tel URI in the international format, the S-CSCF shall translate the E.164 address (see RFC 3966 [22]) to a 
globally routeable SIP URI using an ENUM/DNS translation mechanism with the format specified in 
RFC 3761 24]. Databases aspects of ENUM are outside the scope of the present document. If this translation 
fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g a MRFC to play an 
announcement) in the originator's home network or the S-CSCF may send an appropriate SIP response to the 
originator. When forwarding the request to a BGCF or any other appropriate entity, the S-CSCF shall leave 
the original Request-URI containing the tel URI unmodified. If the request is forwarded, the S-CSCF shall 
remove the access-network-charging-info parameter from the P-Charging- Vector header prior to forwarding 
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the message. If the outgoing Request-URI is a pres URI or an im URI, the S-CSCF shall forward the request 
as specified in RFC 3861 [63]. In this case, the S-CSCF shall not modify the received Request-URI; 

a tel URI in non-international format (i.e. the local service number analysis and handling is either failed in 
the appropriate AS or the request has not been forwarded to AS for local service number analysis and 
handling at all), either forward the request to a BGCF or any other appropriate entity (e.g a MRFC to play an 
announcement) in the originator's home network or send an appropriate SIP response to the originator. 

1 l)determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header if present, 
otherwise based on the Request-URI. If the destination requires interconnect functionalities (e.g. the destination 
address is of an IP address type other than the IP address type used in the IM CN subsystem), the S-CSCF shall 
forward the request to the destination address via an IBCF in the same network; 

12) if network hiding is needed due to local policy, put the address of the IBCF to the topmost route header; 

13) in case of an initial request for a dialog: 

a) determine the need for GRUU processing. GRUU processing is required if: 

an original dialog identifier that the S-CSCF previously placed in a Route header is not present in the 
topmost Route header of the incoming request (this means the request is not returning after having been 
sent to an AS), and 

the contact address contains a valid GRUU as specified in subclause 5.4.7A.4. 

b) if GRUU processing is not required and the initial request originated from a served user, then determine the 
need to record-route for other reasons: 

if the request is routed to an AS which is part of the trust domain, the S-CSCF can decide whether to 
record-route or not. The decision is configured in the S-CSCF using any information in the received 
request that may otherwise be used for the initial filter criteria. If the request is record-routed the S-CSCF 
shall create a Record-Route header containing its own SIP URI; or 

if the request is routed elsewhere, create a Record-Route header containing its own SIP URI; 

NOTE 5: For requests originated from a PSI the S-CSCF can decide whether to record-route or not based on 
operator policy. 

c) if GRUU processing is required, the S-CSCF shall create a Record-Route header containing its own SIP URI; 

d) if GRUU processing is required, the S-CSCF shall save an indication that GRUU-routeing is to be performed 
for in-dialog requests that reach the S-CSCF because of the Record-route header added in step c); 

NOTE 6: The manner of representing the GRUU-routeing indication is a private matter for the S-CSCF. The 

indication is used during termination processing of in-dialog requests to cause the S-CSCF to replace a 
Request-URI containing a GRUU with the corresponding registered contact address. It can be saved using 
values in the Record-Route header, or in dialog state. 

14)based on the destination user (Request-URI), remove the P-Access-Network-Info header and the access-network- 
charging-info parameter in the P-Charging-Vector header prior to forwarding the message; 

15)route the request based on SIP routeing procedures; and 

16) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed. 

When the S-CSCF receives, an initial request for a dialog or a request for a standalone transaction, from an AS acting 
on behalf of an unregistered user, the S-CSCF shall: 

I) execute the procedures described in the steps 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16 in the above 
paragraph (when the S-CSCF receives, from a registered served user, an initial request for a dialog or a request 
for a standalone transaction). 
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NOTE 7: When the S-CSCF does not have the user profile, before executing the actions as listed above, it initiates 
the S-CSCF Registration/deregistration notification with the purpose of downloading the relevant user 
profile (i.e. for unregistered user) and informs the HSS that the user is unregistered. The S-CSCF will 
assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. 

If the S-CSCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response from the 
AS, the S-CSCF shall: 

if the default handling defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 
3GPP TS 29.228 [14] or no default handling is indicated, execute the procedure from step 4; and 

- if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified 
in 3GPP TS 29.228 [14], either forward the received response or, if the request is an initial INVITE request, send 
a 408 (Request Timeout) response or a 5xx response towards the served UE as appropriate (without verifying the 
matching of filter criteria of lower priority and without proceeding for further steps). 

If the S-CSCF receives any final response from the AS, it shall forward the response towards the served UE (without 
verifying the matching of filter criteria of lower priority and without proceeding for further steps). 

When the S-CSCF receives any response to the above request, the S-CSCF may: 

1) apply any privacy required by RFC 3323 [33] and RFC 3325 [34] to the P-Asserted-Identity header. 

NOTE 8: The P-Asserted-Identity header would normally only be expected in Ixx or 2xx responses. 

NOTE 9: The optional procedure above is in addition to any procedure for the application of privacy at the edge of 
the trust domain specified by RFC 3325 [34]. 

When the S-CSCF receives any response to the above request containing a term-ioi parameter, the S-CSCF shall store 
the value of the received term-ioi parameter received in the P-Charging- Vector header, if present, and remove all 
received ioi parameters from the forwarded response if next hop is not an AS. 

NOTE 10: Any received term-ioi parameter will be a type 2 term-ioi or type 3 term-ioi. The term-ioi parameter 
identifies the sending network of the response message. 

When the S-CSCF receives any response to the above request, and forwards it to AS, the S-CSCF shall insert a P- 
Charging- Vector header containing the orig-ioi parameter, if received in the request, and a type 3 term-ioi parameter in 
the response. The S-CSCF shall set the type 3 term-ioi parameter to a value that identifies the sending network of the 
response and the type 3 orig-ioi parameter is set to the previously received value of type 3 orig-ioi. 

When the S-CSCF receives any Ixx or 2xx response to the initial request for a dialog, if the response corresponds to an 
INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in the response in order to be 
able to release the session if needed. 

When the S-CSCF, upon sending an initial INVITE request that includes an IP address in the SDP offer (in "c=" 
parameter), receives an error response indicating that the the IP address type is not supported, (e.g., the S-CSCF 
receives the 488 (Not Acceptable Here) with 301 Warning header indicating "incompatible network address format"), 
the S-CSCF shall either: 

- fork the initial INVITE request to the IBCF; or 

process the error response and forward it using the Via header. 

When the S-CSCF receives from the served user a target refresh request for a dialog, prior to forwarding the request the 
S-CSCF shall: 

1) remove its own URI from the topmost Route header; 

2) create a Record-Route header containing its own SIP URI; 

3) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed; 

4) in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS 
located outside the trust domain, remove the P-Access-Network-Info header and the access-network-charging- 
info parameter in the P-Charging- Vector header; and 
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5) route the request based on the topmost Route header. 

When the S-CSCF receives any Ixx or 2xx response to the target refresh request for a dialog, if the response 
corresponds to an INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in the 
response such that the S-CSCF is able to release the session if needed. 

When the S-CSCF receives from the served user a subsequent request other than a target refresh request for a dialog, 
prior to forwarding the request the S-CSCF shall: 

1) remove its own URJ from the topmost Route header; 

2) in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS 
located outside the trust domain, remove the P- Access-Network-Info header and the access-network-charging- 
info parameter in the P-Charging- Vector header; and 

3) route the request based on the topmost Route header. 

With the exception of 305 (Use Proxy) responses, the S-CSCF shall not recurse on 3xx responses. 

5.4.3.3 Requests terminated at the served user 

When the S-CSCF receives, destined for a statically pre -configured PSI or a registered served user, an initial request for 
a dialog or a request for a standalone transaction, prior to forwarding the request, the S-CSCF shall: 

1) check if an original dialog identifier that the S-CSCF previously placed in a Route header is present in the 
topmost Route header of the incoming request. 

If present, the request has been sent from an AS in response to a previously sent request. 

If not present, it indicates that the request is visiting the S-CSCF for the first time and in this case the S- 
CSCF shall determine whether the request contains a barred public user identity in the Request-URI of the 
request or not. In case the Request-URI contains a barred public user identity for the user, then the S-CSCF 
shall reject the request by generating a 404 (Not Found) response. Otherwise, the S-CSCF shall save the 
Request-URI from the request and continue with the rest of the steps; 

2) remove its own URI from the topmost Route header; 

3) if there was an original dialog identifier present in the topmost Route header of the incoming request check 
whether the Request-URI equals to the saved value of the Request-URI. If there is no match, then: 

a) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in 
the request such that the S-CSCF is able to release the session if needed; and 

b) forward the request based on the topmost Route header or if not available forward the request based on the 
Request-URI (routing based on Request-URI is specified in steps 10 through 14 from subclause 5.4.3.2) and 
skip the following steps. 

3 A) if the Request-URI is a GRUU, but is not valid as defined in subclause 5.4.7A.4, then return a 4xx response 
as as specified in draft-ietf-sip-gruu [93]; 

Editor" s Note: The mechanism for communicating the public user identity to an AS when the Request-URI contains 
a temporary GRUU is FFS. 

4) check whether the initial request matches the next unexecuted initial filter criteria based on the public user 
identity in the Request-URI in the priority order and apply the filter criteria on the SIP method as described in 
3GPP TS 23.218 [5] subclause 6.5. If there is a match, then the S-CSCF shall: 

insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI 
populated as specified in the subclause 5.4.3.4; and 

insert a type 3 orig-ioi parameter in the P-Charging- Vector header. The type 3 orig-ioi parameter identifies 
the sending network of the request message before the received orig-ioi. The S-CSCF shall not include the 
type 3 term-ioi parameter; 
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NOTE 1: Depending on the result of the previous process, the S-CSCF may contact one or more AS(s) before 
processing the outgoing Request-URI. 

5) if there was no original dialog identifier present in the topmost Route header of the incoming request insert a P- 
Charging -Function- Addresses header field, if not present, populated with values received from the HSS if the 
message is forwarded within the S-CSCF home network, including towards AS; 

6) if there was no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the icid parameter received in the P-Charging-Vector header and retain the icid parameter in the P- 
Charging-Vector header; 

7) if there was no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the orig-ioi parameter received in the P-Charging-Vector header, if present, and remove all received ioi 
parameters from the forwarded request if next hop is not an AS; 

NOTE 2: Any received orig-ioi parameter will be a type 2 orig-ioi. or type 3 orig-ioi. The type 2 orig-ioi parameter 
identifies the sending network of the request message. 

8) in the case there are no Route headers in the request, create a target set of potential routes from the the list of 
preloaded routes saved during registration or re-registration as described in subclause 5.4.1.2, as follows: 

a) if the Request-URI is a valid GRUU as defined in subclause 5.4.7A.4, then the target set is determined by 
following the procedures for Request Targeting specified in draft-ietf-sip-gruu [93], using the public user 
identity and instance ID derived from the GRUU using the procedures of subclause 5.4. 7A; 

b) if the Request-URI is not a GRUU, then the target set is all the registered contacts saved for the destination 
public user identity; 

9) if necessary perform the caller preferences to callee capabilities matching according to RFC 3841 [56B] to the 
target set; 

NOTE 3: This might eliminate entries and reorder the target set. 

10) in case there are no Route headers in the request: 

a) if there is more than one route in the target set determined in steps 8) and 9) above: 

if the fork directive in the Request Disposition header was set to "no-fork", use the contact with the 
highest qvalue parameter when building the Request-URI. In case no qvalue parameters were provided, 
the S-CSCF shall decide locally what contact address to be used when building the Request-URI; 
otherwise 

fork the request or perform sequential search based on the relative preference indicated by the qvalue 
parameter of the Contact header in the original REGISTER request, as described in RFC3261 [26]. In 
case no qvalue parameters were provided, then the S-CSCF determine the contact address to be used 
when building the Request-URI as directed by the Request Disposition header as described in 
RFC 3841 [56B]. If the Request-Disposition header is not present, the S-CSCF shall decide locally 
whether to fork or perform sequential search among the contact addresses; 

in case that no route is chosen, return a 480 (Temporarily unavailable) response or another appropriate 
unsuccessful SIP response and terminate these procedures. 

b) build a Request-URI with the contents of the Contact URI from the chosen route determined in the previous 
step; and 

c) build the Route header field with the Path values from the chosen route; and 

d) save the Request-URI and the total number of Record-route headers as part of the dialog request state. 

NOTE 4: For each initial dialog request terminated at a served user two pieces of state are maintained to assist in 

processing GRUUs: the chosen contact address to which the request is routed; and the position of an entry 
for the S-CSCF in the Record-Route header that will be responsible for GRUU translation, if needed (the 
position is the number of entries in the list before the entry was added). The entry will be added in step 5) 
of the below procedures for handling S-CSCF receipt any Ixx or 2xx response to the initial request for a 
dialog. The S-CSCF can record-route multiple times, but only one of those (the last) will be responsible 
for gruu translation at the terminating end. 
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1 l)if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed; 

12) optionally, apply any privacy required by RFC 3323 [33] and RFC 3325 [34] to the P-Asserted-Identity header 
and privacy required by RFC 4244 [66]; 

NOTE 5: The optional procedure above is in addition to any procedure for the application of privacy at the edge of 
the trust domain specified by RFC 3325 [34]. 

13) in case of an initial request for a dialog, either: 

if the request is routed to an AS which is part of the trust domain, the S-CSCF can decide whether to record- 
route or not. The decision is configured in the S-CSCF using any information in the received request that 
may otherwise be used for the initial filter criteria. If the request is record-routed the S-CSCF shall create a 
Record-Route header containing its own SIP URI; or 

if the request is routed elsewhere, create a Record-Route header containing its own SIP URI; and 

14) forward the request based on the topmost Route header. 

If the S-CSCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response from the 
AS, the S-CSCF shall: 

if the default handling defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 
3GPP TS 29.228 [14] or no default handling is indicated, execute the procedure from step 4; and 

- if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified 
in 3GPP TS 29.228 [14], either forward the received response or, if the request is an initial INVITE request, send 
a 408 (Request Timeout) response or a 5xx response towards the originating UE as appropriate (without 
verifying the matching of filter criteria of lower priority and without proceeding for further steps). 

If the S-CSCF receives any final response from the AS, it shall forward the response towards the originating UE 
(without verifying the matching of filter criteria of lower priority and without proceeding for further steps). 

When the S-CSCF receives any response to the above request and forwards it to AS, the S-CSCF shall insert a P- 
Charging- Vector header containing the orig-ioi parameter, if received in the request, and a type 3 term-ioi parameter in 
the response. The S-CSCF shall set the type 3 term-ioi parameter to a value that identifies the sending network of the 
response and the orig-ioi parameter is set to the previously received value of orig-ioi. 

NOTE 6: Any received term-ioi parameter will be a type 3 term-ioi. The term-ioi parameter identifies the service 
provider from which the response was sent. 

When the S-CSCF receives, destined for an unregistered user, an initial request for a dialog or a request for a standalone 
transaction, the S-CSCF shall: 

1) Void. 

2) execute the procedures described in. 

3) In case that no AS needs to be contacted, then S-CSCF shall return an appropriate unsuccessful SIP response. 
This response may be a 480 (Temporarily unavailable) and terminate these procedures. 

NOTE 7: When the S-CSCF does not have the user profile, before executing the actions as listed above, it initiates 
the S-CSCF Registration/deregistration notification with the purpose of downloading the relevant user 
profile (i.e. for unregistered user) and informs the HSS that the user is unregistered. The S-CSCF will 
assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. When 
requesting the user profile the S-CSCF can include the information in the P-Private-Key header in S- 
CSCF Registration/deregistration notification. 

Prior to performing S-CSCF Registration/Deregistration procedure with the HSS, the S-CSCF decides which HSS to 
query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPP TS 29.228 [14]. The HSS address received in the response to SLF query can be used to address the HSS of the 
public user identity with further queries. 

When the S-CSCF receives any Ixx or 2xx response to the initial request for a dialog (whether the user is registered or 
not), it shall: 
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1) if the response corresponds to an INVITE request, save the Contact and Record-Route header field values in the 
response such that the S-CSCF is able to release the session if needed; 

2) if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first 
executed initial filter criteria), insert a type 2 term-ioi parameter in the P-Charging- Vector header of the outgoing 
response. The type 2 term-ioi is set to a value that identifies the sending network of the response and the orig-ioi 
parameter is set to the previously received value of orig-ioi. Values of orig-ioi and term-ioi in the received 
response are removed; 

3) in the case where the S-CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity 
header is an alias SIP URI for a tel URI, the S-CSCF shall add a second P-Asserted-Identity header containing 
this tel URI, including the display name associated with the tel URI, if available. If the P-Asserted-Identity 
header contains only a tel URI, the S-CSCF shall add a second P-Asserted-Identity header containing a SIP URI. 
The added SIP URI shall contain in the user part a "+" followed by the international public telecommunication 
number contained in tel URI, and user's home domain name in the hostport part. The added SIP URI shall 
contain the same value in the display name as contained in the tel URI. The S-CSCF shall also add a user 
parameter equals "phone" to the SIP URI; 

4) in case the response is sent towards the originating user, the S-CSCF may remove the P-Access-Network-Info 
header based on local policy rules and the destination user (Request-URI); and 

5) save an indication that GRUU routing is to be performed for subsequent requests sent within this same dialog if: 

a) there is a record-route position saved as part of the initial dialog request state; and 

b) the contact address in the response is a valid GRUU as specified in subclause 5.4.7A.4. 

NOTE 8: There could be several responses returned for a single request, and the decision to insert or modify the 

Record-Route needs to be applied to each. But a response might also return to the S-CSCF multiple times 
as it is routed back through AS. The S-CSCF will take this into account when carrying out step 5) to 
ensure that the information is stored only once. 

When the S-CSCF receives a response to a request for a standalone transaction (whether the user is registered or not), in 
the case where the S-CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity header is an 
alias SIP URI for a tel URI, the S-CSCF shall add a second P-Asserted-Identity header containing this tel URI, 
including the display name associated with the tel URI, if available. If the P-Asserted-Identity header contains only a tel 
URI, the S-CSCF shall add a second P-Asserted-Identity header containing a SIP URI. The added SIP URI shall contain 
in the user part a "+" followed by the international public telecommunication number contained in tel URI, and user's 
home domain name in the hostport part. The added SIP URI shall contain the same value in the display name as 
contained in the tel URI. The S-CSCF shall also add a user parameter equals "phone" to the SIP URI. In case the 
response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P-Access-Network- 
Info header and the access-network-charging-info parameter in the P-Charging-Vector header; otherwise, the S-CSCF 
shall remove the P-Access-Network-Info header and the access-network-charging-info parameter in the P-Charging- 
Vector header. 

When the S-CSCF receives the 200 (OK) response for a standalone transaction request, the S-CSCF shall: 

1) insert a P-Charging-Function- Addresses header populated with values received from the HSS if the message is 
forwarded within the S-CSCF home network, including towards an AS; and 

2) if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first 
executed initial filter criteria), insert a type 2 term-ioi parameter in the P-Charging-Vector header of the outgoing 
response. The type 2 term-ioi is set to a value that identifies the sending network of the response and the type 2 
orig-ioi parameter is set to the previously received value of orig-ioi. 

When the S-CSCF receives, destined for a served user, a target refresh request for a dialog, prior to forwarding the 
request, the S-CSCF shall: 

1) if the incoming request is received on a dialog for which GRUU routing is to be performed and the Request-URI 
is not the GRUU for this dialog, then return a response of 400 (Bad Request). 

2) if the incoming request is received on a dialog for which GRUU routing is to be performed and the Request-URI 
contains the GRUU for this dialog then the S-CSCF shall: 
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perform the procedures for Request Targeting specified in draft-ietf-sip-gruu [93], using the public user 
identity and instance ID derived from the Request-URI, as specified in subclause 5. 4.7 A; 

if no contact can be selected, return a response of 480 (Temporarily Unavailable). 

3) remove its own URI from the topmost Route header; 

4) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed; 

5) create a Record-Route header containing its own SIP URI; and 

6) forward the request based on the topmost Route header. 

When the S-CSCF receives any Ixx or 2xx response to the target refresh request for a dialog (whether the user is 
registered or not), the S-CSCF shall: 

1) if the response corresponds to an INVITE request, save the Record-Route and Contact header field values in the 
response such that the S-CSCF is able to release the session if needed; and 

2) in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P- 
Access-Network-Info header and the access-network-charging-info parameter in the P-Charging-Vector header; 
otherwise, the S-CSCF shall remove the P-Access-Network-Info header and the access-network-charging-info 
parameter in the P-Charging-Vector header. 

When the S-CSCF receives, destined for the served user, a subsequent request other than target refresh request for a 
dialog, prior to forwarding the request, the S-CSCF shall: 

1) if the incoming request is received on a dialog for which GRUU routing is to be performed and the Request-URI 
is not the GRUU for this dialog, then return a response of 400 (Bad Request). 

2) if the incoming request is received on a dialog for which GRUU routing is to be performed and the Request-URI 
contains the GRUU for this dialog then the S-CSCF shall: 

perform the procedures for Request Targeting specified in draft-ietf-sip-gruu [93], using the public user 
identity and instance ID derived from the Request-URI, as specified in subclause 5. 4. 7 A; 

if no contact can be selected, return a response of 480 (Temporarily Unavailable). 

3) remove its own URI from the topmost Route header; and 

4) forward the request based on the topmost Route header. 

When the S-CSCF receives a response to a a subsequent request other than target refresh request for a dialog, in case 
the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P-Access- 
Network-Info header and the access-network-charging-info parameter from the P-Charging-Vector header; otherwise, 
the S-CSCF shall remove the P-Access-Network-Info header and the access-network-charging-info parameter from the 
P-Charging-Vector header. 

With the exception of 305 (Use Proxy) responses, the S-CSCF shall not recurse on 3xx responses. 

5.4.3.4 Original dialog identifier 

The original dialog identifier is an implementation specific token that the S-CSCF encodes into the own S-CSCF URI in 
a Route header, prior to forwarding the request to an AS. This is possible because the S-CSCF is the only entity that 
creates and consumes the value. 

The token may identify the original dialog of the request, so in case an AS acting as a B2BUA changes the dialog, the 
S-CSCF is able to identify the original dialog when the request returns to the S-CSCF. In a case of a standalone 
transaction, the token indicates that the request has been sent to the S-CSCF from an AS in response to a previously sent 
request. The token can be encoded in different ways, such as e.g., a character string in the user -part of the S-CSCF URI, 
a parameter in the S-CSCF URI or port number in the S-CSCF URI. 

The S-CSCF shall ensure that the value chosen is unique so that the S-CSCF may recognize the value when received in 
a subsequent message and make the proper association between related dialogs that pass through an AS. 
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5.4.3.5 Void 

5.4.4 Call initiation 

5.4.4.1 Initial INVITE 

When the S-CSCF receives an INVITE request, either from the served user or destined to the served user, the S-CSCF 
may require the periodic refreshment of the session to avoid hung states in the S-CSCF. If the S-CSCF requires the 
session to be refreshed, it shall apply the procedures described in RFC 4028 [58] clause 8. 

NOTE 1: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When the S-CSCF receives an initial INVITE request destined for the served user, it shall either: 

a) examine the SDP offer (the "c=" parameter) to detect if it contains an IP address type that is not supported by 
the IM CN subsystem; or 

b) process the initial INVITE request without examining the SDP. 

NOTE 2: If the SDP offer contained an IP address type that is not supported by the IM CN subsystem, the S-CSCF 
will receive the 488 (Not Acceptable Here) response with 301 Warning header indicating "incompatible 
network address format". 

Subsequently, when the S-CSCF detects that the SDP offer contained an IP address type that is not supported by the IM 
CN subsystem (i.e., either case a) or b)), the S-CSCF shall either: 

return a 305 (Use Proxy) response to the I-CSCF with the Contact field containing the SIP URI of the IBCF, or 

- forward the initial INVITE request to the IBCF. When forwarding the initial INVITE request, the S-CSCF shall 
not insert its SIP URI into the Record-Route header. 

5.4.4.2 Subsequent requests 

5.4.4.2.1 UE-originating case 

When the S-CSCF receives any Ixx or 2xx response, the S-CSCF shall insert a P-Charging-Function-Addresses header 
populated with values received from the HSS if the message is forwarded within the S-CSCF home network, including 
towards AS. 

When the S-CSCF receives the request containing the access-network-charging-info parameter in the P-Charging- 
Vector, the S-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header. The S- 
CSCF shall retain access-network-charging-info parameter in the P-Charging-Vector header when the request is 
forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P- 
Charging- Vector header when the request is forwarded outside the home network of the S-CSCF. 

When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a UE-originated dialog or standalone transaction, the S-CSCF may insert previously saved values into P- 
Charging-Vector and P-Charging-Function- Addresses headers before forwarding the message within the S-CSCF home 
network, including towards AS. 

5.4.4.2.2 UE-terminating case 

When the S-CSCF receives the any Ixx or 2xx response, the S-CSCF shall insert a P-Charging-Function-Addresses 
header populated with values received from the HSS if the message is forwarded within the S-CSCF home network, 
including towards AS. 

When the S-CSCF receives 180 (Ringing) or 200 (OK) (to INVITE) responses containing the access-network-charging- 
info parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info parameter from the 
P-Charging-Vector header. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging- 
Vector header when the response is forwarded to an AS. However, the S-CSCF shall not include the access-network- 
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charging-info parameter in the P-Charging- Vector header when the response is forwarded outside the home network of 
the S-CSCF. 

When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a UE-terminated dialog or standalone transaction, the S-CSCF may insert previously saved values into P- 
Charging-Vector and P-Charging-Function-Addresses headers before forwarding the message within the S-CSCF home 
network, including towards AS. 

5.4.5 Call release 

5.4.5.1 S-CSCF-initiated session release 

5.4.5.1 .1 Cancellation of a session currently being established 

Upon receipt of an network internal indication to release a session which is currently being established, the S-CSCF 
shall cancel the related dialogs by sending the CANCEL request according to the procedures described in 
RFC 3261 [26]. 

5.4.5.1 .2 Release of an existing session 

Upon receipt of a network internal indication to release an existing multimedia session, the S-CSCF shall: 

1) generate the first BYE request for the called user based on the information saved for the related dialog, 
including: 

a Request-URI, set to the stored Contact header provided by the called user; 

a To header, set to the To header value as received in the 200 OK response for the initial INVITE request; 

a From header, set to the From header value as received in the initial INVITE request; 

a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user, 
incremented by one; 

a Route header, set to the routeing information towards the called user as stored for the dialog; 

a Reason header that contains proper SIP response code; 

further headers, based on local policy. 

2) generate the second BYE request for the calling user based on the information saved for the related dialog, 
including: 

a Request-URI, set to the stored Contact header provided by the calling user; 

a To header, set to the From header value as received in the initial INVITE request; 

a From header, set to the To header value as received in the 200 OK response for the initial INVITE request; 

a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user, 
incremented by one - if no CSeq value was stored for that session it shall generate and apply a random 
number within the valid range for CSeqs; 

a Route header, set to the routeing information towards the calling user as stored for the dialog; 

a Reason header that contains proper SIP response code; 

- further headers, based on local policy. 
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3) if the S-CSCF serves the calHng user, treat the first BYE request as if received directly from the calling user, i.e. 
send it to internal service control and based on the outcome further on towards the called user; 

4) if the S-CSCF serves the calling user, send the second BYE request directly to the calling user. 

5) if the S-CSCF serves the called user, send the first BYE request directly to the called user; 

6) if the S-CSCF serves the called user, treat the second BYE request as if received directly from the called user, 
i.e. shall send it to internal service control and based on the outcome further on towards to the calling user. 

Upon receipt of the 2xx responses for both BYE requests, the S-CSCF shall release all information related to the dialog 
and the related multimedia session. 

5.4.5.1 .2A Release of the existing dialogs due to registration expiration 

When the registration lifetime of the only public user identity currently registered with its associated set of implicitly 
registered public user identities (i.e. no other is registered) expires while there are still active multimedia sessions that 
includes this user, where the session was initiated with the public user identity currently registered or with one of the 
implicitly registered public used identities, the S-CSCF shall release each of these multimedia sessions by applying the 
steps listed in the subclause 5.4.5.1.2. 

5.4.5.1.3 Abnormal cases 

Upon receipt of a request on a dialog for which the S-CSCF initiated session release, the S-CSCF shall terminate the 
received request and answer it with a 481 (Call/Transaction Does Not Exist) response. 

5.4.5.2 Session release initiated by any other entity 

Upon receipt of a 2xx response for a BYE request matching an existing dialog, the S-CSCF shall delete all the stored 
information related to the dialog. 

5.4.5.3 Session expiration 

If the S-CSCF requested the session to be refreshed periodically, and the S-CSCF got the indication that the session will 
be refreshed, when the session timer expires, the S-CSCF shall delete all the stored information related to the dialog. 

5.4.6 Call-related requests 
5.4.6.1 RelNVITE 

5.4.6.1 .1 Determination of served user 
Void. 

5.4.6.1.2 UE-originating case 

For a relNVITE request or UPDATE request from the UE within the same dialog, the S-CSCF shall store the updated 
access-network-charging-info parameter from P-Charging-Vector header in the received SIP request. The S-CSCF shall 
retain the access-network-charging-info parameter in the P-Charging- Vector header when the request is forwarded to an 
AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector 
header when the request is forwarded outside the home network of the S-CSCF. 

For a relNVITE request from the UE, if the request is to be forwarded to an AS that is located within the trust domain, 
the S-CSCF shall retain the P-Access-Network-Info header and the access-network-charging-info parameter from the P- 
Charging-Vector header; otherwise, the S-CSCF shall remove the P-Access-Network-Info header and the access- 
network-charging-info parameter from the P-Charging-Vector header. 
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5.4.6.1 .3 UE-terminating case 

For a relNVITE request or UPDATE request destined towards the UE within the same dialog, when the S-CSCF 
receives the 200 (OK) response (to the INVITE request or UPDATE request), the S-CSCF shall store the updated 
access-network-charging-info parameter from the P-Charging- Vector header. The S-CSCF shall retain the access- 
network-charging-info parameter in the P-Charging- Vector header when the response is forwarded to the AS. However, 
the S-CSCF shall include the access-network-charging-info parameter in the P-Charging-Vector header when the 200 
(OK) response is forwarded outside the home network of the S-CSCF. 

For any SIP response to an INVITE request, if the response is to be forwarded to an AS that is located within the trust 
domain, the S-CSCF shall retain the P-Access-Network-Info header and the access-network-charging-info parameter 
from the P-Charging- Vector header; otherwise, the S-CSCF shall remove the P-Access-Network-Info header and the 
access-network-charging-info parameter from the P-Charging-Vector header. 

5.4.7 Void 

5.4.7A GRUU management 
5.4.7A.1 Overview of GRUU operation 

The S-CSCF provides a service of assigning and translating GRUUs for use by registered UEs. This is conducted as 
specified in draft-ietf-sip-gruu [93] and draft-ietf-sipping-gruu-reg-event [94]. Two kinds of GRUUs are assigned: 
public GRUUs and temporary GRUUs. 

Each assigned GRUU represents an association between a public user identity and an instance ID provided by a 
registering UE. It is used to address a particular UE that possesses the instance ID and registers with the public user 
identity. The GRUU also denotes a contact address registered with a public user identity when the contact address has a 
"H-sip. instance" header parameter containing the the GRUU instance ID. 

The S-CSCF issues GRUUs as part of the registration process, and also reports GRUUs as part of notifications for 
subscriptions to the "reg" event package. The S-CSCF always issues GRUUs in pairs - a public GRUU and a temporary 
GRUU. 

5.4.7A.2 Representation of public GRUUs 

Each public GRUU shall conform to all requirements specified in draft-ietf-sip-gruu [93]. 

The S-CSCF constructs a public GRUU by adding a "gr" URI parameter to a public user identity. The "gr" parameter 
serves as an indicator that the URI is in fact a GRUU and carries a value that encodes the instance ID. 

By default, the value of the "gr" parameter is a copy of the value of the "sip. instance" header parameter from a Contact 
address registered with the S-CSCF, with escaping of special characters as specified in RFC3261 [26]. A different 
representation of the instance ID may be specified for specific forms of instance ID. 

Editor" s Note: The specification of such additional specific representations of the instance ID is FFS. 

The public GRUU for a particular association of public user identity and instance ID is persistent. The same public 
GRUU will be returned each time a registration is performed with a particular pair of public user identity and instance 
ID. 

5.4.7A.3 Representation of temporary GRUUs 

Each temporary GRUU shall conform to all requirements specified in draft-ietf-sip-gruu [93]. 

Each temporary GRUU shall contain a "gr" URI parameter, which serves as an indicator that the URI is in fact a 
GRUU. It shall not contain a value. 

Because of the limited hfetime of an temporary GRUU, only the S-CSCF that created a temporary GRUU is required to 
understand how to translate that GRUU to the corresponsing public user identity and instance ID. 

The specific representation of a temporary GRUU may be decided by each S-CSCF implementation. Temporary 
GRUUs must route to the assigning S-CSCF without requiring each assigned GRUU to be stored in the HSS. 
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The S-CSCF may choose a representation of temporary GRUUs that requires no extra state to be retained, such as that 
specified in draft-ietf-sip-gruu [93]. Alternatively, the S-CSCF may choose a stateful representation. This is an 
implementation choice. 

NOTE: One possible implementation is for the S-CSCF to have a statically configured wildcard PSI that routes to 
it, with each temporary GRUU being encoded so that it matches the wildcard. 

5.4.7A.4 GRUU recognition and validity 

The S-CSCF shall be able to recognize those GRUUs it has assigned, verify their validity, and extract the associated 
public user identity and instance ID. This is true for both public GRUUs and temporary GRUUs. 

GRUUs are distinguished from other URIs by the presence of a "gr" URI parameter. Public GRUUs are distinguished 
from temporary GRUUs by the presence of a value for the "gr" URI parameter. 

The instance ID is derived from a public GRUU by decoding the value of the "gr" parameter in conformance with the 
encoding rules specified in sub-clause 5.4.7A.2. The public user identity is extracted from a public GRUU by removing 
the "gr" URI parameter. 

The S-CSCF can recognize a public GRUU as valid if the derived instance ID is a syntactically correct URN, and the 
derived public user identity compares equal, according to the comparison rules of RFC3261 [26], to a public user 
identity active within the S-CSCF. 

The public user identity and instance ID are derived from a temporary GRUU via implementation specific means 
consistent with the way temporary GRUUs are constructed. The validity of a temporary GRUU shall be determined in 
conformance with draft-ietf-sip-gruu [93], and is determined using implementation specific means. 



5.4.8 Emergency service 



5.4.8.1 General 

S-CSCF shall handle the emergency registration as per the needs of the normal registration. 

Editor's note: This subclause needs furthehr study related to the differences between emergency registration and 
nomral registration. Emergency registration may have an impact on Cx interface, so we may cooperate 
with CT4 in futher study. 

For all registrations identified as relating to an emergency public user identity, the S-CSCF shall give priority over other 
transactions. This allows special treatment (e.g. with respect to filtering, higher priority, routeing) of emergency 
registrations. The exact meaning of priority is not defined further in this document, but is left to national regulation and 
network configuration. 

5.4.8.2 Initial emergency registration or user-initiated emergency reregistration 

When the S-CSCF receives a REGISTER request without an "integrity-protected" parameter, or with the "integrity- 
protected" parameter in the Authorization header set to "no" and the To header includes an emergency public user 
identity the S-CSCF shall perform the actions as specified in subclause 5.4.1.2.1. 

When the S-CSCF receives a REGISTER request with the "integrity-protected" parameter in the Authorization header 
set to "yes", the S-CSCF shall identify the user by the public user identity as received in the To header and the private 
user identity as received in the Authorization header of the REGISTER request the S-CSCF shall perform the actions as 
specified in subclause 5.4.1.2.2 with the following additions: 

- the S-CSCF shall not include a Service-Route in the 200 (OK) to the REGISTER request; 

store the Path header and the contact information including all header parameters contained in the Contact 
header. The S-CSCF shall use the Path header and the contact information obtained during the emergency 
registration to build a preloaded Route header values for the emergency dialogs destined for the UE; and 

NOTE 1 : The Path header and contact information used for the emergency dialogs destined for the UE and obtained 
during the emergency registration can be different than the Path header used for the non-emergency 
communication and obtained during the non-emergency registration. 
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NOTE 2: If the previous emergency registration with different contact information or emergency Path header has 
not expired, the S-CSCF will not perform the network initiated deregistration procedure for the previous 
emergency registration, but will let it expire. 

- the S-CSCF shall not send any third-party REGISTER requests to any AS. 

5.4.8.3 User-initiated emergency deregistration 

When S-CSCF receives a REGISTER request with the Expires header field containing the value zero and the To header 
includes an emergency public user identity as specified in 3GPP TS 23.003 [3], the S-CSCF shall reject the REGISTER 
request by sending a 501 (Not Implemented) response. 

NOTE: The UE cannot deregister its emergency pubhc user identity. 

5.4.8.4 Network-initiated emergency deregistration 

The S-CSCF shall not perform a network-initiated emergency deregistration for an emergency public user identity. 

5.4.8.5 Network-initiated emergency reauthentication 

The S-CSCF shall not reauthenticate an emergency public user identity. 

5.4.8.6 Subscription to the event providing registration state 

If a S-CSCF receives a SUBSCRIBE request addressed to S-CSCF containing the Event header with the reg event 
package with a emergency public user identity in the To header, the S-CSCF shall reject the SUBSCRIBE request for 
the reg-event package by sending a 489 (Bad Event) response. 

5.4.8.7 Notification of the registration state 

The S-CSCF shall not send a NOTIFY requestaddressed to an emergency public user identity regarding its subscription 
state. 

5.5 Procedures at the MGCF 
5.5.1 General 

The MGCF, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to 
be known by peer-to-peer arrangements within the IM CN subsystem. Therefore table A.4/1 and dependencies on that 
major capability shall not apply. 

The use of the Path and Service-Route headers shall not be supported by the MGCF. 

When the MGCF sends any request or response related to a dialog, the MGCF may insert previously saved values into 
P-Charging-Vector and P-Charging-Function- Addresses headers before sending the message. 

The MGCF shall use a GRUU referring to itself (as specified in draft-ietf-sip-gruu [93]) when inserting a contact 
address in a dialog establishing or target refreshing SIP message. This specification does not define how GRUUs are 
created by the MGCF; they can be provisioned by the operator or obtained by any other mechanism. A GRUU used by 
the MGCF when establishing a dialog shall remain valid for the lifetime of the dialog. 

The MGCF shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which 
the GRUU was provided. 

EXAMPLE: Upon receipt of an INVITE request addressed to a GRUU assigned to a dialog it has active, and 
containing a Replaces header referencing that dialog, the MGCF will be able to establish the new 
call replacing the old one. 
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5.5.2 Subscription and notification 

Void. 

5.5.3 Call initiation 
5.5.3.1 Initial INVITE 

5.5.3.1 .1 Calls originated from circuit-switched networks 

When the MGCF receives an indication of an incoming call from a circuit-switched network, the MGCF shall: 

1) generate an INVITE request: 

set the Request-URI to the "tel" format using an E. 164 address or to the "sip" format using an E164 address 
in the user portion and set user=phone; 

NOTE 1 : Details how to set the host portion are out of scope of the document. However, when a SIP URI is used 
the host portion needs to be part of the domain name space owned by the I-CSCF 

- set the Supported header to " lOOrel" (see RFC 3312 [30] as updated by RFC 4032 [64])); 

include an P-Asserted-Identity header, including the display name if available, depending on corresponding 
information in the circuit-switched network; 

create a new, globally unique value for the icid parameter and insert it into the P-Charging- Vector header; 
and 

insert a type 2 orig-ioi parameter into the P-Charging-Vector header. The MGCF shall set the type 2 orig-ioi 
parameter to a value that identifies the sending network in which the MGCF resides and the type 2 term-ioi 
parameter shall not be included. 

When the MGCF receives a Ixx or 2xx response to an initial request for a dialog, the MGCF shall store the value of the 
received term-ioi parameter received in the P-Charging- Vector header, if present. 

NOTE 2: Any received term-ioi parameter will be a type 2 term-ioi. The type 2 term-ioi parameter identifies the 
sending network of the response message. 

5.5.3.1 .2 Calls terminating in circuit-switched networks 

When the MGCF receives an initial INVITE request with Supported header indicating "lOOrel", the MGCF shall: 

1) store the value of the orig-ioi parameter received in the P-Charging -Vector header, if present; 

NOTE: Any received orig-ioi parameter will be a type 2 orig-ioi. The orig-ioi parameter identifies the sending 
network of the request message. 

2) send a 100 (Trying) response; 

3) after a matching codec is found or no codec is required at the MGW, send 183 "Session Progress" response: 

set the Require header to the value of "lOOrel"; 

store the values received in the P-Charging-Function- Addresses header; 

store the value of the icid parameter received in the P-Charging-Vector header; and 

insert a P-Charging- Vector header containing the orig-ioi parameter, if received in the initial INVITE request 
and a type 2 term-ioi. The MGCF shall set the type 2 term-ioi parameter to a value that identifies the network 
in which the MGCF resides and the orig-ioi parameter is set to the previously received value of orig-ioi. 

If a codec is required and the MGCF does not find an available matching codec at the MGW for the received initial 
INVITE request, the MGCF shall: 
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send 503 (Service Unavailable) response if the type of codec was acceptable but none were available; or 

send 488 (Not Acceptable Here) response if the type of codec was not supported, and may include SDP in the 
message body to indicate the codecs supported by the MGCF/MGW. 

5.5.3.2 Subsequent requests 

5.5.3.2.1 Calls originating in circuit-switched networks 

When the MGCF receives 183 (Session Progress) response to an INVITE request, the MGCF shall: 

store the values received in the P-Charging-Function- Addresses header. 
The MGCF shall send an UPDATE request when the following conditions are fulfilled: 

- conditions as specified in 3GPP TS 29.163 [IIB]; and 

- the MGCF receives 200 (OK) response to a PRACK request 

5.5.3.2.2 Calls terminating in circuit-switched networks 

When the MGCF receives an indication of a ringing for the called party of outgoing call to a circuit-switched network, 
the MGCF shall: 

send 180 (Ringing) response to the UE. 

When the MGCF receives an indication of answer for the called party of outgoing call to a circuit-switched network, the 
MGCF shall: 

send 200 (OK) response to the UE. The 200 (OK) response shall include an P-Asserted-Identity header if 
corresponding information is received from the circuit-switched network. 

5.5.4 Call release 

5.5.4.1 Call release initiated by a circuit-switched network 

When the MGCF receives an indication of call release from a circuit-switched network, the MGCF shall: 
send a BYE request to the UE. 

5.5.4.2 IM CN subsystem initiated call release 

NOTE: The release of a call towards the circuit-switched network additionally requires signaling procedures other 
than SIP in the MGCF that are outside the scope of this document. 

5.5.4.3 MGW-initiated call release 

When the MGCF receives an indication from the MGW that the bearer was lost, the MGCF shall: 
send a BYE request towards the UE; and 
may include Error-Info header witha pointer to additional information indicating that bearer was lost. 

5.5.5 Call-related requests 

5.5.5.1 RelNVITE 

5.5.5.1 .1 Calls originating from circuit-switched networks 

Void. 
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5.5.5.1 .2 Calls terminating in circuit-switched networks 

When the MGCF receives a relNVITE request for hold/resume operation, the MGCF shall: 
send 100 (Trying) response; 
after performing interaction with MGW to hold/resume the media flow, send 200 (OK) response. 

5.5.6 Further initial requests 

When the MGCF responds to an OPTIONS request with a 200 (OK) response, the MGCF may include a message body 
with an indication of the DTMF capabilities and supported codecs of the MGCF/MGW. 

NOTE: The detailed interface for requesting MGCF/MGW capabilities is not specified in this version of the 
document. Other solutions may be used in the interim. 

5.6 Procedures at the BGCF 

5.6.1 General 

The use of the Path and Service-Route headers shall not be supported by the BGCF. 

When the BGCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a dialog or standalone transaction, the BGCF may insert previously saved values into P-Charging- Vector and 
P-Charging-Function- Addresses headers before forwarding the message. 

With the exception of 305 (Use Proxy) responses, the BGCF may recurse on a 3xx response only when the domain part 
of the URI contained in the 3xx response is in the same domain as the BGCF. For the same cases, if the URI is an IP 
address, the BGCF shall only recurse if the IP address is known locally to be a address that represents the same domain 
as the BGCF. 

5.6.2 Common BGCF procedures 

When determining where to route the received request, the originating BGCF may use the information obtained from 
other protocols or any other available databases. 

When the BGCF receives a request, the BGCF shall forward the request: 

to an MGCF within its own network; or 

to another network containing a BGCF, or I-CSCF; or 

where the request is for another network, to an IBCF in its own network, if local policy requires IBCF 
capabilities towards another network. 

When forwarding the request to the next hop, the BGCF may leave the received Request-URI unmodified. 

The BGCF need not Record-Route the INVITE request. While the next entity may be a MGCF acting as a UA, the 
BGCF shall not apply the procedures of RFC 3323 [33] relating to privacy. The BGCF shall store the values received in 
the P-Charging-Function- Addresses header. The BGCF shall store the value of the icid parameter received in the P- 
Charging- Vector header and retain the icid parameter in the P-Charging-Vector header. 

NOTE 1 : The means by which the decision is made to forward to an MGCF or to another network is outside the 
scope of the present document, but may be by means of a lookup to an external database, or may be by 
data held internally to the BGCF. 

When the BGCF receives an INVITE request, if the BGCF inserts its own Record-Route header, the BGCF may require 
the periodic refreshment of the session to avoid hung states in the BGCF. If the BGCF requires the session to be 
refreshed, it shall apply the procedures described in RFC 4028 [58] clause 8. 

NOTE 2: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 
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5.7 Procedures at the Application Server (AS) 
5.7.1 Common Application Server (AS) procedures 
5.7.1 .1 Notification about registration status 

The AS may support the REGISTER method in order to discover the registration status of the user. If a REGISTER 
request arrives and the AS supports the REGISTER method, the AS shall store the Expires parameter from the request 
and generate a 200 (OK) response or an appropriate failure response. For the success case, the 200 (OK) response shall 
contain Expires value equal to the value received in the REGISTER request. The AS shall store the values received in 
P-Charging-Function- Addresses header. Also, the AS shall store the values of the icid parameter and orig-ioi parameter 
if present in the P-Charging- Vector header from the REGISTER request. The AS shall insert a P-Charging-Vector 
header containing the orig-ioi parameter, if received in the REGISTER request and a type 3 term-ioi parameter in the 
response to REGISTER. The AS shall set the type 3 term-ioi parameter to a value that identifies the service provider 
from which the response is sent and the orig-ioi parameter is set to the previously received value of orig-ioi. 

Upon receipt of a third-party REGISTER request, the AS may subscribe to the reg event package for the public user 
identity registered at the user's registrar (S-CSCF) as described in RFC 3680 [43]. 

On sending a SUBSCRIBE request, the AS shall populate the header fields as follows: 

a) a Request URI set to the resource to which the AS wants to be subscribed to, i.e. to a SIP URI that contains the 
public user identity of the user that was received in the To header field of the third-party REGISTER request; 

b) a From header field set to the AS's SIP URI; 

c) a To header field, set to a SIP URI that contains the public user identity of the user that was received in the To 
header field of the third-party REGISTER request; 

d) an Event header set to the "reg" event package; 

e) a P-Asserted-Identity header field set to the SIP URI of the AS; and 

NOTE 1: The S-CSCF expects the SIP URI used in the P-Asserted-Identity header to correspond to the SIP URI, 
which identified this AS in the initial filter criteria of the user to whose registration state the AS 
subscribes to. 

f) a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17] and a type 3 
orig-ioi parameter. The type 3 orig-ioi identifies the service provider from which the request is sent. The AS 
shall not include the type 3 term-ioi parameter. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the AS shall store the information for the so established 
dialog and the expiration time as indicated in the Expires header of the received response. 

Upon receipt of any response, the AS shall store the value of the term-ioi parameter received in the P-Charging-Vector 
header if present. 

NOTE 2: Any received term-ioi parameters will be any type term-ioi but includes the adjacent network term ioi in 
frst position. The first term-ioi identifies the network operator from which the response was originated 
for a release 5 S-CSCF and the network operator from which the request was sent otherwise. 

NOTE 3: Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to 
"terminated" (i.e. all public user identities are deregistered) and the Subscription-State header set to 
"terminated", the AS considers the subscription to the reg event package terminated, i.e. as if the AS had 
sent a SUBSCRIBE request with an Expires header containing a value of zero. 

Upon receipt of a NOTIFY request, the AS shall store the value of the orig-ioi parameters if present in the P-Charging- 
Vector header. The AS shall insert a P-Charging-Vector header in the response to the NOTIFY rquest containing the 
orig-ioi parameter, if received in the NOTIFY request and a type 3 term-ioi. The AS shall set the type 3 term-ioi 
parameter to a value that identifies the service provider from which the response is sent and the orig-ioi parameter is set 
to the previously received value of orig-ioi. 
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5.7.1 .2 Extracting charging correlation information 

When an AS receives an initial request for a dialog or a request (excluding ACK requests and CANCEL requests and 
responses) for a standalone transaction, the AS shall store the values received in the P-Charging- Vector header, e.g. 
orig-ioi parameter, if present, and icid parameter, and retain the P-Charging-Vector header in the message. The AS shall 
store the values received in the P-Charging-Function- Addresses header and retain the P-Charging-Function- Addresses 
header in the message. 

When an AS sends any request or response related to a dialog or standalone transaction, the AS may insert previously 
saved values into the P-Charging-Vector and P-Charging-Function-Addresses headers before sending the message. 

5.7.1.3 Access-Network-Info and Visited-Network-ID 

The AS may receive in any request or response (excluding ACK requests and CANCEL requests and responses) 
information about the served user access network. The AS may receive information about the served user core network 
in REGISTER requests from S-CSCF. This information is contained in the P-Access-Network-Info header and P- 
Visited-Network-ID header. The AS can use the headers to provide an appropriate service to the user. 

5.7.1 .4 User identify verification at the AS 

The procedures at the AS to accomplish user identity verification are described with the help of figure 5-1. 

NOTE: Different means can be used to represent or transport the credentials. Such mechanisms are subject to 
operator policy and can e.g. include the P-Asserted-Identity header, the Authorization header or other 
mechanisms not specified by 3GPP TS 24.229. 

When the AS receives a SIP initial or standalone request, excluding REGISTER request, that does not contain 
credentials, the AS shall: 

a) if a Privacy header is present in the initial or standalone request and the Privacy header value is set to "id" or 
"user", then the user and the request are considered as anonymous, and no further actions are required. The AS 
shall consider the request as authenticated; 

b) if there is no Privacy header present in the initial or standalone request, or if the Privacy header contains a value 
other than "id" or "user", then the AS shall check for the presence of a P-Asserted-Identity header in the initial or 
standalone request. Two cases exists: 

i) the initial or standalone request contains a P-Asserted-Identity header. This is typically the case when the 
user is located inside a trusted domain as defined by subclause 4.4. In this case, the AS is aware of the 
identity of the user and no extra actions are needed. The AS shall consider the request as authenticated. 

ii) the initial or standalone request does not contain a P-Asserted-Identity header. This is typically the case when 
the user is located outside a trusted domain as defined by subclause 4.4. In this case, the AS does not have a 
verified identity of the user. The AS shall check the From header of the initial or standalone request. If the 
From header value in the initial or standalone request is set to "Anonymous" as specified in RFC 3261 [26], 
then the user and the request are considered as anonymous and no further actions are required. If the From 
header value does not indicate anonymity, then the AS shall challenge the user by issuing a 401 
(Unauthorized) response including a challenge as per procedures described in RFC 3261 [26]. 

When the AS receives a SIP initial or standalone request that contains credentials but it does not contain a P-Asserted- 
Identity header the AS shall check the correctness of the credentials as follows: 

a) If the credentials are correct, then the AS shall consider the identity of the user verified, and the AS shall 
consider the request as authenticated; 

b) If the credentials are not correct, the AS may either rechallenge the user by issuing a 401 (Unauthorized) 
response including a challenge as per procedures described in RFC 3261 [26] (up to a predetermined maximum 
number of times predefined in the AS configuration data), or consider the user as anonymous. If the user is 
considered anonymous, the PS shall consider the request as authenticated. 
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Figure 5-1 : User identity verification flow at the AS 
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5.7.1 .5 Request authorization 

Once the AS have tried to verify the identity of the user, the AS either has a verified identity of the user or it considers 
the user as anonymous. 

If the user is considered anonymous, the AS shall check whether the authorization policy defined for this request allows 
anonymous requests. If anonymous requests are allowed, then the AS can proceed with the requested functionality, 
otherwise, the AS shall not proceed with the requested functionality. 

If the user is identified by an identity, the AS shall apply the authorization policy related to the requested functionaUty 
to detect whether the particular user is allowed to request the functionality. The authorization policy may require a 
verified identity of a user. 

If the request is authorized then the AS shall continue with the procedures as defined for that request. 

If the request is not authorized, the AS shall either: 

reject the request according to the procedures defined for that request e.g., by issuing a 403 (Forbidden) 
response; or 

send a 2xx final response if the authorization policy requires to deny the requested functionality, whilst 
appearing to the user as if the request has been granted. 

5.7.1 .6 Event notification throttling 

If the AS has a local configuration information limiting the rate at which notification generation is allowed, then the AS 
shall take that information into account. Such local configuration information could be e.g. the shortest time period 
between issuing consecutive NOTIFY requests. 

5.7.1.7 Local numbering 

5.7.1 .7.1 Interpretation of the local service number 

If home operator"s local policy defines a prefix string(s) to enable subscribers to differentiate dialing a geo-local service 
number and/or a home-local service number and if the phone number in a non-international format in the Request URI 
includes such a prefix in the dialled local service number, the AS shall interpret the received local service number as a 
geo-local service number or as a home-local service number according to the prefix. 

If the phone number in a non-international format in the Request URI includes a "phone-context" parameter, the AS 
shall interpret the received local service number: 

1) as a geo-local service number, if the "phone -context" parameter contains access technology information; 

2) as a home-local service number, if the "phone-context" parameter contains the home domain name; or 

3) as a local service number in a third network, if the "phone-context" parameter contains any other value. 

If the phone number in a non-international format in the Request URI includes both operator defined prefix in the 
dialled local service number and a "phone-context" parameter and those information are contradictory, the AS shall 
ignore either the prefix or the "phone-context" parameter according to operator policy. 

If the phone number in a non-international format in the Request URI does not include either a phone-context parameter 
or an operator defined prefix in the dialled local service number, the AS shall interpret the received local service 
number as a geo-local service number or as a home-local service number according to operator policy. 

NOTE: Operator must ensure that service setting dialing strings do not reach local numbering AS by setting 
appropriately the precedences of the initial filter criteria. 

5.7.1 .7.2 Translation of the local service number 

Editor's note: The text in this subclause must be aligned with local service number definitions in stage 2. 

When an AS receives a request having a geo-local service number in a non-international format in the Request URI, the 
AS shall use the "phone-context" parameter to determine the visited access network, if "phone-context" parameter in the 
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Request-URI is available. If "phone-context" parameter in the Request-URI is not available, the AS may determine the 
visited access network based on P- Access-Network-Info header, if it is available in the received request, or by means 
outside the scope of this document. 

If the visited access network is determined the AS shall attempt to determine whether the geo-local service number is 
used to access a service in the visited network or the local addressing plan of the visited network and translate the 
received geo-local service number to a globally routable SIP URI or an international tel URJ: 

NOTE 1 : During the translation the AS can contact an entity in the visited access network for getting the needed 
information. The protocol and procedures for this is outside the scope of this specification. 

When an AS receives a request having a home-local service number in a non-international format in the Request URI, 
the AS shall determine whether the home-local service number is used to access a service or the local addressing plan 
and translate the received home-local service number to a globally routable SIP URI or an international tel URI: 

When an AS receives a request having a local service number in a third network in a non-international format in the 
Request URJ, the AS shall attempt to determine whether the local service number is used to access a service in the third 
network or the local addressing plan of the third network and translate the received local service number to a globally 
routable SIP URI or an international tel URJ: 

NOTE 2: The AS can translate the tel URI to a SIP URI by including the 'telephone-subscriber' part of the received 
tel URI to the user part of the SIP URI and setting the domain name of the SIP URI to indicate the 
domain name of the network of the phone number based on the received "phone-context" parameter; 

If the translation at the AS fails, the AS shall either send an appropriate SIP response or route the request based on the 
topmost Route header, based on local policy. 

5.7.1 .8 GRUU assignment and usage 

It shall be possible for an AS to use a GRUU referring to itself when inserting a contact address in a dialog establishing 
or target refreshing SIP message. When using a GRUU, it shall do do in conformance with draft-ietf-sip-gruu [93]. 

This specification does not define how GRUUs are created by the AS; they can be provisioned by the operator or 
obtained by any other mechanism. The GRUU shall remain valid for the time period in which features addressed to it 
remain meaningful. 

The AS shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which the 
GRUU was provided. 

EXAMPLE: Upon receipt of an INVITE request addressed to a GRUU assigned to a dialog it has active, and 
containing a Replaces header referencing that dialog, the AS will be able to establish the new call 
replacing the old one, if that is appropriate for the features being provided by the AS. 

When an AS is acting as a routeing B2BUA (as defined in subclause 5.7.5) it may provide a contact address that is not a 
GRUU when the contact address in the incoming message that is being replaced is not a GRUU. In all other cases it 
shall use a GRUU. 

When an AS acts as UA or Initiating B2BUA it may provide a contact address that is not a GRUU in cases where it can 
ascertain that valid requests that could result from the use of that contact and follow the usage rules of draft-ietf-sip- 
gruu [93] will reach the element. In all other cases a GRUU shall be used. 

Editor"s Note: If, when, and how features are applied to new requests addressed to a GRUU assigned by an AS, and 
the implications of that on how GRUUs are assigned by an AS, is for future study. 

Editor"s Note: How the AS can indicate privacy while using a GRUU in the contact address is for future study. 

5.7.2 Application Server (AS) acting as terminating UA, or redirect server 

When acting as a terminating UA the AS shall behave as defined for a UE in subclause 5.1.4, with the exceptions 
identified in this subclause. 

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be 
known by peer-to-peer arrangements within the IM CN subsystem. 
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An AS acting as redirect server shall propagate any received IM CN subsystem XML message body in the redirected 

message. 

When an AS acting as a terminating UA generates a subsequent request that does not relate to an INVITE dialog, the 
AS shall insert a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]. 

When the AS acting as terminating UA receives an initial request for a dialog or a request for a standalone transaction, 
it shall store the value of the orig-ioi parameters received in the P-Charging- Vector header if present. 

NOTE: received orig-ioi parameters will be any type orig-ioi but includes the adjacent network term ioi in frst 
position. The first orig-ioi identifies the network operator from which the request was originated for a 
release 5 S-CSCF and the network operator from which the request was sent otherwise. 

When the AS acting as terminating UA generates a response to an initial request for a dialog or a request for a 
standalone transaction, it shall insert a P-Charging-Vector header containing the orig-ioi parameter, if received in the 
request and a type 3 term-ioi. The AS shall set the type 3 term-ioi parameter to a value that identifies the service 
provider from which the response is sent and the orig-ioi parameter is set to the previously received value of orig-ioi. 

5.7.3 Application Server (AS) acting as originating UA 

In order to support an AS acting as an originating UA, the AS has to be within the same trust domain as the S-CSCF to 
which requests will be sent. 

When acting as an originating UA the AS shall behave as defined for a UE in subclause 5.1.3, with the exceptions 
identified in this subclause. 

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be 
known by peer-to-peer arrangements within the IM CN subsystem. 

When an AS acting as an originating UA generates an initial request for a dialog or a request for a standalone 
transaction, the AS shall insert a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 
32.260 [17] and a type 3 orig-ioi. The AS shall set the type 3 orig-ioi parameter to a value that identifies the service 
provider from which the request is sent. The AS shall not include the type 3 term-ioi parameter. 

NOTE 1: The AS can retrieve CCF and/or ECF addresses from HSS on Sh interface. 

When the AS acting as an originating UA receives any response to an initial request for a dialog or a request for a 
standalone transaction, it shall store the value of the term-ioi parameter received in the P-Charging- Vector header if 
present. 

NOTE 2: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the network 
operator from which the response was sent. 

When an AS acting as an originating UA generates a subsequent request that does not relate to an INVITE dialog, the 
AS shall insert a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]. 

The AS shall extract charging function addresses from any P-Charging-Function- Addresses header that is received in 
any Ixx or 2xx responses to the requests. 

The AS may also indicate that the proxies should not fork the request by including a "no-fork" directive within the 
Request-Disposition header in the request as described in RFC 3841 [56B]. 

When sending an initial request on behalf of a PSI that is hosted by the AS, the AS shall: 

insert a Route header pointing either to the S-CSCF where the PSI is hosted or to the entry point of the home 
network of the PSI, if the AS is not able to resolve the next hop address by itself or the operator policy requires 
it; or 

forward the originating request directly to the destination without involving any S-CSCF in the originating IM 
CN subsystem, if the AS is able to resolve the next hop address by itself, and the operator policy allows it. 

NOTE 3: The address of the S-CSCF hosting the PSI can be obtained by querying the HSS on the Sh interface. 
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When sending an initial request on behalf of a public user identity, the AS shall insert a Route header pointing to the S- 
CSCF where the public user identity on whose behalf the request is generated is registered or hosted (unregistered case) 
or to the entry point of the public user identity's network. 

NOTE 4: The address of the S-CSCF can be obtained either by querying the HSS on the Sh interface or during 
third-party registration. 

For the use of the P-Asserted-Identity by the AS, at least two cases exist: 

a) any initial request for a dialog or request for a standalone transaction is generated as if it was originated by the 
UE on whose behalf the request is generated. In this case the AS shall insert a P-Asserted-Identity representing a 
public user identity of that UE. The AS shall append the "orig" parameter to the URI in the topmost Route 
header; and 

b) any initial request for a dialog or request for a standalone transaction is generated by an AS supporting a service 
identified by a PSI. In this case the AS shall insert a P-Asserted-Identity containing the PSI of the AS. Also, the 
AS shall append the "orig" parameter to the URI in the topmost Route header. 

NOTE 5: AS can only send the initial request to the entry point of the public user identity's network or to the entry 
point of the home network of the PSI only if the AS can assume (e.g. based on local configuration) that 
the receiving entry point will be able to process the request as an originating request. 

The AS can indicate privacy of the P-Asserted-Identity in accordance with RFC 3323 [33], and the additional 
requirements contained within RFC 3325 [34]. 

Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the AS shall set the 
From header to "Anonymous" as specified in RFC 3261 [26]. 

NOTE 6: The contents of the From header cannot be relied upon to be modified by the network based on any 
privacy specified by the user either within the AS indication of privacy or by network subscription or 
network policy. Therefore the AS includes the value "Anonymous" whenever privacy is explicitly 
required. 

5.7.4 Application Server (AS) acting as a SIP proxy 

When the AS acting as a SIP proxy receives a request from the S-CSCF, prior to forwarding the request it shall: 

remove its own URI from the topmost Route header; and 

after executing the required services, route the request based on the topmost Route header. 

The AS may modify the SIP requests based on service logic, prior to forwarding the request back to the S-CSCF. 

The AS shall not fork the request if the fork-directive in the Request-Disposition header is set to "no-fork" as described 
in RFC 3841 [56B]. 

An AS acting as a SIP proxy shall propagate any received IM CN subsystem XML message body in the forwarded 

message. 

When the AS acting as a SIP proxy receives an initial request for a dialog or a request for a standalone transaction, it 
shall store the value of the orig-ioi parameter received in the P-Charging-Vector header if present. The AS shall remove 
the orig-ioi parameter from the forwarded request. 

NOTE: Any received orig-ioi parameters will be any type orig-ioi but includes the adjacent network term ioi in 

frst position. The first orig-ioi identifies the network operator from which the request was originated for a 
release 5 S-CSCF and the network operator from which the request was sent otherwise. 

When the AS acting as a SIP proxy generates a response to an initial request for a dialog or a request for a standalone 
transaction, it shall insert a P-Charging-Vector header containing the orig-ioi parameter, if received in the request and a 
type 3 term-ioi. The AS shall set the type 3 term-ioi parameter to a value that identifies the service provider from which 
the response is sent and the orig-ioi parameter is set to the previously received value of orig-ioi. Any values of orig-ioi 
or term-ioi received in any response that is being forwarded are not used. 
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5.7.5 Application Server (AS) performing 3rd party call control 

5.7.5.1 General 

The AS performing 3rd party call control acts as a B2BUA. There are two kinds of 3rd party call control: 

Routeing B2BUA: an AS receives a request from the S-CSCF, terminates it and generates a new request, which 
is based on the received request. 

Initiating B2BUA: an AS initiates two requests, which are logically connected together at the AS, or an AS 
receives a request from the S-CSCF and initiates a new request that is logically connected but unrelated to the 
incoming request from the originating user (e.g. the P-Asserted-Identity of the incoming request is changed by 
the AS). 

When the AS receives a terminated call and generates a new call, and dependent on whether the service allows the AS 
to change the P-Asserted-Identity for outgoing requests compared with the incoming request, the AS will select 
appropriate kind of 3rd party call control. 

The B2BUA AS will internally map the message headers between the two dialogs that it manages. It is responsible for 
correlating the dialog identifiers and will decide when to simply translate a message from one dialog to the other, or 
when to perform other functions. These decisions are specific to each AS and are outside the scope of the present 
document. 

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be 
known by peer-to-peer arrangements within the IM CN subsystem. 

For standalone transactions, when the AS is acting as a Routeing B2BUA, the AS shall copy the remaining Route 
header(s) unchanged from the received request for a standalone transation to the new request for a standalone 
transaction. 

When the AS acting as a routeing B2BUA receives an initial request for a dialog or a request for a standalone 
transaction, it shall store the value of the orig-ioi parameter received in the P-Charging-Vector header if present. The 
AS shall remove the orig-ioi parameter from the forwarded request. 

NOTE: Any received orig-ioi parameters will be any type orig-ioi but includes the adjacent network term ioi in 

frst position. The first orig-ioi identifies the network operator from which the request was originated for a 
release 5 S-CSCF and the network operator from which the request was sent otherwise. 

When the AS acting as a routeing B2BUA generates a response to an initial request for a dialog or a request for a 
standalone transaction, it shall insert a P-Charging-Vector header containing the orig-ioi parameter, if received in the 
request and a type 3 term-ioi. The AS shall set the type 3 term-ioi parameter to a value that identifies the service 
provider from which the response is sent and the orig-ioi parameter is set to the previously received value of orig-ioi. 
Any values of orig-ioi or term-ioi received in any response that is being forwarded are not used. 

5.7.5.2 Call initiation 
5.7.5.2.1 Initial INVITE 

When the AS acting as a Routeing B2BUA receives an initial INVITE request from the S-CSCF, the AS shall: 

remove its own SIP URI from the topmost Route header of the received INVITE request; 

- perform the AS specific functions. See 3GPP TS 23.218 [5]; 

if successful, generate and send a new INVITE request to the S-CSCF to establish a new dialog; 

copy the remaining Route header(s) unchanged from the received INVITE request to the new INVITE request; 

copy the P-Asserted-Identity to the outgoing request; and 

route the new INVITE request based on the topmost Route header. 

NOTE 1: The topmost Route header of the received INVITE request will contain the AS's SIP URI. The following 
Route header will contain the SIP URI of the S-CSCF. 
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When the AS is acting as an Initiating B2BUA, the AS shall apply the procedures described in subclause 5.7.3 for any 
outgoing requests. The AS shall either set the icid parameter in the P-Charging-Vector header to be the same as 
received or different. 

NOTE 2: The AS can retrieve CCF and/or ECF adresses from HSS on Sh interface. 

5.7.5.2.2 Subsequent requests 

Void. 

5.7.5.3 Call release 

5.7.5.4 Call-related requests 

An AS may initiate a call release. See 3GPP TS 23.218 [5] for possible reasons. The AS shall simultaneously send the 
BYE request for both dialogs managed by the B2BUA. 

5.7.5.5 Further initial requests 

When the AS is acting as an Initiating B2BUA the AS shall apply the procedures described in subclause 5.7.3 for both 
requests. The AS shall either set the icid parameter in the P-Charging-Vector header to be the same as received or 
different. 

5.7.6 Void 

5.8 Procedures at the MRFC 
5.8.1 General 

Although the MRFC is acting as a UA, it is outside the scope of this specification how the MRFC associated addresses 
are made known to other entities. 

When the MRFC sends any request or response (excluding ACK requests and CANCEL requests and responses) related 
to a dialog or standalone transaction, the MRFC may insert previously saved values into P-Charging-Vector and P- 
Charging-Function-Addresses headers before sending the message. 

The MRFC shall use a GRUU referring to itself (as specified in draft-ietf-sip-gruu [93]) when inserting a contact 
address in a dialog establishing or target refreshing SIP message. This specification does not define how GRUUs are 
created by the MRFC; they can be provisioned by the operator or obtained by any other mechanism. A GRUU used by 
the MRFC when establishing a dialog shall remain valid for the lifetime of the dialog. 

The MRFC shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which 
the GRUU was provided. 

EXAMPLE: Upon receipt of an INVITE request addressed to a GRUU assigned to a dialog it has active, and 

containing a Replaces header referencing that dialog, the MRFC will be able to establish the new 
call replacing the old one. 
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5.8.2 Call initiation 

5.8.2.1 Initial INVITE 

5.8.2.1 .1 MRFC-terminating case 

5.8.2.1.1.1 Introduction 

The MRFC shall provide a P-Asserted-Identity header in a response to the initial request for a dialog, or any response 
for a standalone transaction. It is a matter of network policy whether the MRFC expresses privacy according to 
RFC 3323 [33] with such responses. 

When the MRFC receives an initial INVITE request, the MRFC shall store the values received in the P-Charging- 
Vector header, e.g. icid parameter. The MRFC shall store the values received in the P-Charging-Function- Addresses 
header. 

5.8.2.1 .1 .2 Tones and announcements 

The MRFC can receive INVITE requests to set up a session to play tones and announcements. The MRFC acts as 
terminating UA in this case. 

When the MRFC receives an INVITE request with an indicator for a tone or announcement, the MRFC shall: 

send 100 (Trying) response. 

NOTE: The detailed interfaces for requesting tones and announcements are not specified in this version of the 
document. Other solutions may be used in the interim. 

5.8.2.1.1.3 Ad-hoc conferences 

The MRFC can receive INVITE requests to set up an ad-hoc conferencing session (e.g. Multiparty Call) or to add 
parties to the conference. The MRFC acts as terminating UA in this case. 

When the MRFC receives an INVITE request with an indicator to initiate ad hoc conferencing, the MRFC shall: 

send 100 (Trying) response; and 

after the MRFP indicates that the conference resources are available, send 200 (OK) response with an MRFC 
conference identifier.If the MRFC chooses to send a 183 (Session Progress) response prior to the 200 (OK), then 
the conference identifier may also be included in the 183 (Session Progress) response. 

When the MRFC receives an INVITE request with an indicator to add a party to an existing ad hoc conference 
(i.e. MRFC conference identifier), the MRFC shall: 

send 100 Trying response; and 

after the MRFP indicates that the conferencing request is granted, send 200 OK response with the MRFC 
conference identifier.If the MRFC chooses to send a 183 Session Progress response prior to the 200 OK, then the 
conference identifier may also be included in the 183 Session Progress response. 

NOTE: The detailed interface for requesting ad-hoc conferencing sessions is not specified in this version of the 
document. Other solutions may be used in the interim. 

5.8.2.1.1.4 Transcoding 

The MRFC may receive INVITE requests to set up transcoding between endpoints with incompatible codecs. The 
MRFC acts as terminating UA in this case. 

When the MRFC receives an INVITE request with an indicator for transcoding and a codec is supplied in SDP, the 
MRFC shall: 

send 100 (Trying) response; and 
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after the MRFP indicates that the transcoding request is granted, send 200 (OK) response. 
When the MRFC receives an INVITE request with an indicator for transcoding but no SDP, the MRFC shall: 
send 183 (Session Progress) response with list of codecs supported by the MRFC/MRFP. 

5.8.2.1 .2 MRFC-originating case 

The MRFC shall provide a P-Asserted-Identity header in an initial request for a dialog, or any request for a standalone 
transaction. It is a matter of network policy whether the MRFC expresses privacy according to RFC 3323 [33] with 
such requests. 

When an MRFC generates an initial request for a dialog or a request for a standalone transaction, the MRFC shall insert 
a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]. 

5.8.2.2 Subsequent requests 

5.8.2.2.1 Tones and announcements 

When the MRFC receives an ACK request for a session, this may be considered as an event to direct the MRFP to start 
the playing of a tone or announcement. 

5.8.3 Call release 

5.8.3.1 S-CSCF-initiated call release 
5.8.3.1 .1 Tones and announcements 

When the MRFC receives a BYE request for a session, the MRFC directs the MRFP to stop the playing of a tone or 
announcement. 

5.8.3.2 MRFC-initiated call release 

5.8.3.2.1 Tones and announcements 

When the MRFC has a timed session to play tones and announcements and the time expires, the MRFC shall: 

send a BYE request towards the UE. 
When the MRFC is informed by the MRFP that tone or announcement resource has been released, the MRFC shall: 

send a BYE request towards the UE. 

5.8.2.2.2 Transcoding 

When the MRFC receives a PRACK request (in response to the 183 (Session Progress) response) with an indicator for 
transcoding and codec supplied in SDP, the MRFC shall: 

after the MRFP indicates that the transcoding request is granted, send 200 (OK) response. 
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5.8.4 Call-related requests 

5.8.4.1 RelNVITE 

5.8.4.1 .1 MRFC-terminating case 

5.8.4.1.1.1 Ad-hoc conferences 

The MRFC can receive relNVITE requests to modify an ad-hoc conferencing session (e.g. Multiparty Call) for 
purposes of floor control and for parties to leave and rejoin the conference. 

When the MRFC receives a relNVITE request, the MRFC shall: 

send 100 (Trying) response; and 

after the MRFP indicates that the conferencing request is granted, send 200 (OK) response with the MRFC 
conference identifier.If the MRFC chooses to send a 183 (Session Progress) response prior to the 200 OK, then 
the conference identifier may also be included in the 183 (Session Progress) response. 

NOTE: The detailed interface for requesting ad-hoc conferencing sessions is not specified in this version of the 
document. Other solutions may be used in the interim. 

5.8.4.1.2 MRFC-originating case 
Void. 

5.8.4.2 REFER 

5.8.4.2.1 MRFC-terminating case 
Void. 

5.8.4.2.2 MRFC-originating case 

Void. 

5.8.4.2.3 REFER initiating a new session 
Void. 

5.8.4.2.4 REFER replacing an existing session 
Void. 

5.8.4.3 INFO 

Void. 



5.8.5 Further initial requests 



When the MRFC responds to an OPTIONS request with a 200 (OK) response, the MRFC may include a message body 
with an indication of the supported tones/announcement packages, DTMF capabilities, supported codecs and 
conferencing options of the MRFC/MRFP. 

NOTE: The detailed interface for requesting MRFC/MRFP capabilities is not specified in this version of the 
document. Other solutions may be used in the interim. 
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5.9 Void 
5.9.1 Void 

5.10 Procedures at tine IBCF 

5.10.1 General 

As specified in 3GPP TS 23.228 [7] border control functions may be applied between two IM CN subsystems or 
between an IM CN subsystem and other SIP-based multimedia networks based on operator preference. The IBCF may 
act both as an entry point and as an exit point for a network. If it processes a SIP request received from other network it 
functions as an entry point (see subclause 5.10.2) and it acts as an exit point whenever it processes a SIP request sent to 
other network (see subclause 5.10.3). 

The functionalities of the IBCF include: 

network configuration hiding (see subclause 5. 10.4); 

application level gateway (see subclause 5.10.5); 

transport plane control, i.e. QoS control; 

screening of SIP signalling (see subclause 5.10.6); and 

inclusion of an IWF if appropriate. 

NOTE: The functionaUties performed by the IBCF are configured by the operator, and it is network specific. 

Editor's note: It is FES, whether a separate subclause needed to describe the transport plane control, or it will be 
added to application level gateway description (as in IBCF the QoS control functionality requires IMS- 
ALG functionaUty). 

5.10.2 IBCF as an exit point 
5.10.2.1 Registration 

When IBCF receives a REGISTER request, the IBCF shall: 

1) if network topology hiding is required, then apply the encryption procedures for the Path header as described in 
subclause 5.10.4.1; 

2) if network topology hiding is required or IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, then the IBCF shall add its own routeable SIP URI to the top of the Path 
header; and 

NOTE 1 : The IBCF can include in the inserted SIP URI an indicator that identifies the direction of subsequent 

requests received by the IBCF i.e., from the S-CSCF towards the P-CSCF, to identify the UE-terminating 
case. The IBCF can encode this indicator in different ways, such as, e.g., a unique parameter in the URI, a 
character string in the username part of the URI, or a dedicated port number in the URI. 

NOTE 2: Any subsequent request that includes the direction indicator (in the Route header) or arrives at the 
dedicated port number, indicates that the request was sent by the S-CSCF towards the P-CSCF. 

3) select an entry point of the home network and forward the request to that entry point. 
If the selected entry point: 

does not respond to the REGISTER request and its retransmissions by the IBCF; or 

sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 
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the IBCF shall select a new entry point and forward the original REGISTER request. 

NOTE 3: The list of the entry points can be either obtained as specified in RFC 3263 [27 A] or provisioned in the 
IBCF. The entry point can be an IBCF or an I-CSCF. 

If the IBCF fails to forward the REGISTER request to any entry point, the IBCF shall send back a 504 (Server 
Time-Out) response to the P-CSCF, in accordance with the procedures in RFC 3261 [26]. 

5.10.2.2 Initial requests 

Upon receipt of any request, except the REGISTER method, the IBCF shall: 

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response; 

2) if the request is an INVITE request and the IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, save the Contact, CSeq and Record-Route header field values received in 
the request such that the IBCF is able to release the session if needed; 

3) if network topology hiding is required, apply the procedures as described in subclause 5. 10.4; 

4) if screening of SIP signalling is required, apply the procedures as described in subclause 5.10.6; 

5) if IBCF processes a request without a pre-defined route (e.g. the subscription to reg event package originated by 
the P-CSCF), select an entry point of the home network and forward the request to that entry point; 

NOTE 1 : The list of the entry points can be either obtained as specified in RFC 3263 [27 A] or provisioned in the 
IBCF. The entry point can be an IBCF or an I-CSCF. 

6) store the values from the P-Charging-Function- Addresses header, if present; and 

7) remove the P-Charging- Vector and the P-Charging-Function- Addresses headers, if present, prior to forwarding 
the message. 

When the IBCF receives an INVITE request, the IBCF may require the periodic refreshment of the session to avoid 
hung states in the IBCF. If the IBCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE 2: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When the IBCF receives a response to the initial request and network topology hiding is required, then the IBCF shall 
apply the procedures as described in subclause 5.10.4. 

When the IBCF receives a response to the initial request and screening of SIP signalling is applied, then the IBCF shall 
apply the procedures as described in subclause 5.10.6. 

5.10.2.3 Subsequent requests 

Upon receipt of any request, except the REGISTER method, the IBCF shall: 

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response; 

2) if the request is a target refresh request and the IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, save the Contact and CSeq header field values received in the request 
such that the IBCF is able to release the session if needed; 

3) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog 
where the method is unknown) and the IBCF is configured to perform application level gateway and/or transport 
plane control functionalities, save the Contact and CSeq header field values received in the request such that the 
IBCF is able to release the session if needed; 

4) if network topology hiding is required, apply the procedures as described in subclause 5.10.4; and 

5) if screening of SIP signalling is required, apply the procedures as described in subclause 5. 10.6. 
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When the IBCF receives a response to the subsequent request and network topology hiding is required, then the IBCF 
shall apply the procedures as described in subclause 5.10.4. 

When the IBCF receives a response to the subsequent request and screening of SIP signalling is required, then the IBCF 
shall apply the procedures as described in subclause 5.10.6. 

5.10.2.4 IBCF-initiated call release 

If the IBCF provides transport plane control functionality and receives an indication of a transport plane related error 
the IBCF may: 

1) generate a BYE request for the terminating side based on information saved for the related dialog; and 

2) generate a BYE request for the originating side based on the information saved for the related dialog. 

NOTE: Transport plane related errors can be indicated from e.g. TrGW or PDF. The protocol for indicating 
transport plane related errors to the IBCF is out of scope of this specification. 

Upon receipt of the 2xx responses for both BYE requests, the IBCF shall release all information related to the dialog 
and the related multimedia session. 

5.10.3 IBCF as an entry point 
5.10.3.1 Registration 

When IBCF receives a REGISTER request, the IBCF shall: 

1) verify if it arrived from a trusted domain or not. If the request arrived from an untrusted domain, respond with 
403 (Forbidden) response; 

NOTE 1 : The IBCF can find out whether the request arrived from a trusted domain or not, from the procedures 
described in 3GPP TS 33.210 [19A]. 

2) if network topology hiding, or screening of SIP signalling, is required or IBCF is configured to perform 
application level gateway and/or transport plane control functionalities, add its own routeable SIP URJ to the top 
of the Path header; and 

NOTE 2: The IBCF can include in the inserted SIP URI an indicator that identifies the direction of subsequent 

requests received by the IBCF i.e., from the S-CSCF towards the P-CSCF, to identify the UE-terminating 
case. The IBCF can encode this indicator in different ways, such as, e.g., a unique parameter in the URI, a 
character string in the username part of the URI, or a dedicated port number in the URI. 

NOTE 3: Any subsequent request that includes the direction indicator (in the Route header) or arrives at the 
dedicated port number, indicates that the request was sent by the S-CSCF towards the P-CSCF. 

3) If IBCF is colocated with an I-CSCF, or it has a preconfigured I-CSCF to be contacted, forward the request to 
that I-CSCF. Otherwise select an I-CSCF and forward the request to that I-CSCF. 

Editor's note: It is FFS, whether for an IBCF in the home network it is useful to allow the I-CSCF selection. It adds 
extra flexibility to the network topology, but adds extra complexity as well. The possible two level re- 
selection can be too much for the SIP timers. 

If the selected I-CSCF: 

does not respond to the REGISTER request and its retransmissions by the IBCF; or 

sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

the IBCF shall select a new I-CSCF and forward the original REGISTER request. 

NOTE 4: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [27 A] or provisioned in the 
IBCF. 
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If the IBCF fails to forward the REGISTER request to any I-CSCF, the IBCF shall send back a 504 (Server Time-Out) 
response towards the P-CSCF, in accordance with the procedures in RFC 3261 [26]. 

5.10.3.2 Initial requests 

Upon receipt of any request, except the REGISTER request, the IBCF shall verify whether the request is arrived from a 
trusted domain or not. If the request arrived from an untrusted domain, then the IBCF shall; 

if the topmost Route header of the request contains the "orig" parameter, respond with 403 (Forbidden) 
response. Otherwise, 

remove all P-Asserted-Identity headers, all P- Access-Network-Info headers, all P-Charging- Vector headers and 
all P-Charging-Function- Addresses headers the request may contain. 

Upon receipt of any request, except the REGISTER request, the IBCF shall: 

1) if the request is an INVITE request, then respond with a 100 (Trying) provisional response; 

2) if the request is an INVITE request and the IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, then the IBCF shall save the Contact, CSeq and Record-Route header 
field values received in the request such that the IBCF is able to release the session if needed; 

3) if network topology hiding is required, then apply the procedures as described in subclause 5. 10.4; and 

4) If IBCF receives an initial request for a dialog or standalone transaction, that contains a single Route header 
pointing to itself, and it is co-located with an I-CSCF, or it has a preconfigured I-CSCF to be contacted, then 
forward the request to that I-CSCF. Otherwise select an I-CSCF and forward the request to that I-CSCF. If the 
single Route header of the request contains the "orig" parameter, the IBCF shall insert the "orig" parameter to the 
URI of the I-CSCF. 

Editor's note: It is FFS, whether for an IBCF in the home network it is useful to allow the I-CSCF selection. It adds 
extra flexibility to the network topology, but adds extra complexity as well. The possible two level re- 
selection can be too much for the SIP timers. 

When the IBCF receives an INVITE request, the IBCF may require the periodic refreshment of the session to avoid 
hung states in the IBCF. If the IBCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When the IBCF receives a response to an initial request (e.g. 183 or 2xx), the IBCF shall: 

1) store the values from the P-Charging-Function- Addresses header, if present; 

2) remove the P-Charging-Function- Addresses header prior to forwarding the message; and 

3) if network topology hiding is required, then the IBCF shall apply the procedures as described in 
subclause 5.10.4. 

5.10.3.3 Subsequent requests 

Upon receipt of any request, except the REGISTER method, the IBCF shall: 

1) if the request is an INVITE request, then respond with a 100 (Trying) provisional response; 

2) if the request is a target refresh request and the IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, then the IBCF shall save the Contact and CSeq header field values 
received in the request such that the IBCF is able to release the session if needed; 

3) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog 
where the method is unknown) and the IBCF is configured to perform application level gateway and/or transport 
plane control functionalities, then the IBCF shall save the Contact and CSeq header field values received in the 
request such that the IBCF is able to release the session if needed; and 
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4) if network topology hiding is required, then apply the procedures as described in subclause 5. 10.4. 

When the IBCF receives a response to the subsequent request and network topology hiding is required, then the IBCF 
shall apply the procedures as described in subclause 5.10.4. 

5.10.3.4 IBCF-initiated call release 

If the IBCF provides transport plane control functionality and receives an indication of a transport plane related error 
the IBCF may: 

1) generate a BYE request for the terminating side based on information saved for the related dialog; and 

2) generate a BYE request for the originating side based on the information saved for the related dialog. 

NOTE: Transport plane related errors can be indicated from e.g. TrGW or PDF. The protocol for indicating 
transport plane related errors to the IBCF is out of scope of this specification. 

Upon receipt of the 2xx responses for both BYE requests, the IBCF shall release all information related to the dialog 
and the related multimedia session. 

5.1 0.4 THIG functionality in the IBCF 

5.10.4.1 General 

NOTE 1 : THIG functionality is performed in I-CSCF in Release-5 and Release-6 and is compatible with the 
procedures specified in this subclause. 

The following procedures shall only be applied if network topology hiding is required by the network. The network 
requiring network topology hiding is called the hiding network. 

NOTE 2: Requests and responses are handled independently therefore no state information is needed for that 
purpose within an IBCF. 

The IBCF shall apply network topology hiding to all headers which reveal topology information, such as Via, Route, 
Record-Route, Service-Route, and Path. 

Upon receiving an incoming REGISTER request for which network topology hiding has to be applied and which 
includes a Path header, the IBCF shall add the routeable SIP URI of the IBCF to the top of the Path header. The IBCF 
may include in the inserted SIP URI an indicator that identifies the direction of subsequent requests received by the 
IBCF i.e., from the S-CSCF towards the P-CSCF, to identify the UE-terminating case. The IBCF may encode this 
indicator in different ways, such as, e.g., a unique parameter in the URI, a character string in the username part of the 
URI, or a dedicated port number in the URI. 

NOTE 3: Any subsequent request that includes the direction indicator (in the Route header) or arrives at the 
dedicated port number, indicates that the request was sent by the S-CSCF towards the P-CSCF. 

Upon receiving an incoming initial request for which network topology hiding has to be applied and which includes a 
Record-Route header, the IBCF shall add its own routeable SIP URI to the top of the Record-Route header. 

5.1 0.4.2 Encryption for network topology hiding 

Upon receiving an outgoing request/response from the hiding network the IBCF shall perform the encryption for 
network topology hiding purposes, i.e. the IBCF shall: 

1) use the whole header values which were added by one or more specific entity of the hiding network as input to 
encryption, besides the UE entry; 

2) not change the order of the headers subject to encryption when performing encryption; 

3) use for one encrypted string all received consecutive header entries subject to encryption, regardless if they 
appear in separate consecutive headers or if they are consecutive entries in a comma separated list in one header; 
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4) construct an NAI in the form of 'username@realm', where the username part is the encrypted string, and the 
realm is the name of the encrypting network; 

5) append a "tokenized-by=" tag and set it to the value of the encrypting network's name, after the constructed NAI; 

6) form one valid entry for the specific header out of the resulting NAI, e.g. prepend "SIP/2.0/UDP" for Via 
headers or "sip:" for Path, Service-Route, Route and Record-Route headers; and 

7) if the IBCF encrypted an entry in the Route header, then it also inserts its own URI before the topmost encrypted 
entry. 

NOTE 1 : Even if consecutive entries of the same network in a specific header are encrypted, they will result in only 
one encrypted header entry. For example: 

Via: SIP/2. 0/UDP ibcf 1 .homel .net; Ir, 

SIP/2. 0/UDP Token ( SIP/2. 0/UDP scscfl . homel . net ; Ir, 

SIP/2. 0/UDP pcscfl.homel.net; Ir) ghomel.net; 
token! zed-by=homel .net, 
SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] 

NOTE 2: If multiple entries of the same network are within the same type of headers, but they are not consecutive, 
then these entries will be tokenized to different strings. For example: 

Record-Route : sip:ibcfl. homel .net; Ir, 

sip: Token (sip: scscfl . homel .net; Ir ) @ homel .net; tokenized-by=homel .net, 

sip:asl. foreign. net; Ir, 

sip: Token (sip: scscfl . homel .net; Ir, 

sip:pcscfl . homel .net; Ir ) (3 homel .net; tokenized-by=homel .net 

NOTE 3: If request will return to the hiding network (e.g. after visiting an AS), then the URI of IBCF is inserted. 
For example: 

Route: sip : asl . foreign .net; Ir, 
sip: ibcfl . homel .net; Ir, 
sip: Token (sip: scscfl . homel .net; Ir ) (? homel .net; tokenized-by=homel .net 

5.1 0.4.3 Decryption for network topology hiding 

Upon receiving and incoming requests/response to the hiding network the IBCF shall perform the decryption for 
network topology hiding purposes, i.e. the IBCF shall: 

1) identify NAIs encrypted by the network this IBCF belongs to within all headers of the incoming message; 

2) use the user part of those NAIs that carry the identification of the hiding network within the value of the 
tokenized-by tag as input to decryption; 

3) use as encrypted string the user part of the NAI which follows the sent-protocol (for Via Headers, e.g. 
"SIP/2.0/UDP") or the URI scheme (for Route and Record-Route Headers, e.g. "sip:"); 

4) replace all content of the received header which carries encrypted information with the entries resulting from 
decryption. 

EXAMPLE: An encrypted entry to a Via header that looks like: 

Via: SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscfl . homel . net ; Ir, 

SIP/ 2 . 0/UDP pcscf 1 . homel .net; Ir ) @ homel . net ; tokenized-by=homel .net 

will be replaced with the following entries: 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; ir, SIP/2. 0/UDP pcscf 1 . homel . net ; ir 

NOTE: Motivations for these decryption procedures are e.g. to allow the correct routeing of a response through 
the hiding network, to enable loop avoidance within the hiding network, or to allow the entities of the 
hiding network to change their entries within e.g. the Record-Route header. 
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5.1 0.5 IMS-ALG functionality in tine IBCF 



The IBCF shall only apply the following procedures if application level gateway functionality is required by the 
network. 

The IBCF acts as a B2BUA when it performs IMS-ALG functionality. As an IMS-ALG, the IBCF will internally map 
the message headers between the two dialogs that it manages. It is responsible for correlating the dialog identifiers and 
will decide when to simply translate a message from one dialog to the other, or when to perform other functions. The 
IBCF, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be 
known by peer-to-peer arrangements within the IM CN subsystem. The use of the Path and Service-Route headers shall 
not be supported by the IMS-ALG. 

When the IBCF receives an initial INVITE request from another SIP network, i.e. it is an entry point, the IBCF shall 
generate a new initial INVITE request and forward it to the I-CSCF. In case the initial INVITE request is received from 
own network, i.e. the IBCF is an exit point, the IBCF shall generate a new initial INVITE request and forward it to the 
entry point of the other network. 

An IBCF may provide a contact address that is not a GRUU when the contact address in the incoming message that is 
being replaced is not a GRUU. In all other cases it shall use a GRUU. When using a GRUU, it shall do so in 
conformance with draft-ietf-sip-gruu [93]. 

This specification does not define how GRUUs are created by the IBCF; they can be provisioned by the operator or 
obtained by any other mechanism. The GRUU shall remain valid for the time period in which features addressed to it 
remain meaningful. 

The IBCF shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which 
the GRUU was provided. 

EXAMPLE: Upon receipt of an INVITE request addressed to a GRUU assigned to a dialog it has active, and 
containing a Replaces header referencing that dialog, the IBCF will be able to establish the new 
call replacing the old one. 

The internal function of the IBCF as an IMS-ALG is defined in 3GPP TS 29.162 [llA]. 

5.1 0.6 Screening of SIP signalling 

5.10.6.1 General 

The IBCF may act as a B2BUA when it performs screening of SIP signalling functionality. In this case the B2BUA 
behaviour of the IBCF shall comply with the description given in subclause 5.10.5 for the IMS-ALG functionality. 

NOTE: Many headers are intended for end-to-end operation; removal of such headers will impact the intended 
end-to-end operation between the end users. Additionally the IM CN subsystem does not preclude 
security mechanisms covering SIP headers; any such removal may prevent validation of all headers 
covered by the security mechanism. 

Editor's note: Further study will be given to specifying procedures that can act in a more transparent manner to the 
end user for some of these screening functions, and therefore allow the screening function to use proxy 
behaviour. Use of draft-ietf-sipping-media-policy-dataset, draft-hilt-sipping-policy-package, draft-hilt- 
sipping-policy-usecases, draft-hilt-sipping-session-policy-framework, draft-hilt-sipping-session-spec- 
policy, draft-camarillo-sipping-sbc-funcs will be investigated for this purpose. 

5.1 0.6.2 IBCF procedures for SIP headers 

If specified by local policy rules, the IBCF may omit or modify any received SIP headers prior to forwarding SIP 
messages, with the following exceptions. 

As a result of any screening policy adopted, the IBCF should not modify at least the following headers which would 
cause misoperation of the IM CN subsystem: 

Authorization; and 

- WWW-Authenticate. 
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Where the IBCF appears in the path between the UE and the S-CSCF, some headers are involved in the registration and 
authentication of the user. As a resuh of any screening poUcy adopted as part of normal operation, e.g. where the 
request or response is forwarded on, the IBCF should not modify as part of the registration procedure at least the 
following headers: 

Path; and 

Service -Route. 

NOTE: Where operator requirements can be achieved by configuration hiding, then these procedures can be used 
in preference to screening. 

Editor's note: It is for further study as to whether the screening function should be able to remove the Route, Record- 
Route, and Via headers, Content-Type, and Accept. 

5.1 0.6.3 IBCF procedures for SIP message bodies 

If IP address translation (NA(P)T or IP version interworking) occurs on the user plane, the IBCF shall modify SDP 
according to the annex F and G as appropriate; 

Additionally, the IBCF may take the foUowings action upon SIP message bodies: 

1) examine the length of a SIP message body and if required by local policy, take an appropriate action (e.g. 
forward the message body transparently, reject the request, remove the body); 

2) examine the characteristics of the message body (i.e. check the values of any Content-Type, Content- 
Disposition, and Content-Language headers), take an appropriate action defined by local policy (e.g. forward the 
body unchanged, remove the body, reject the call); and 

3) examine the content of SIP bodies, and take appropriate action defined by local policy (e.g. forward the body 
unchanged, remove the body, reject the call). 

5.1 1 Procedures at the E-CSCF 
5.11.1 General 

The PSAP may either be directly connected to the IM CN subsystem or via the PSTN. 

The E-CSCF performs the functions of an ESRP to retrieve a PSAP URI, based on the location of the UE. The PSAP 
URI can be retrieved from LRF or from local configuration. The PSAP address will either point to a PSAP connected to 
the IM CN subsystem or to a PSAP connected to the PSTN. 

Editor's Note: It needs to be decided what information the E-CSCF uses to determine the above choice. 

If the E-CSCF fails to select a PSAP based on the received location information contained in an INVITE request, the E- 
CSCF can interrogate the LRF in order to retrieve location information. 

Editor's Note: The protocol used by the E-CSCF to retrieve the location information from the LRF is not decided 

yet. 



5.11.2 UE originating case 



Editor's Note: It seems useful to mention explicitly here that the below text applies to two cases. Case 1 : The 

INVITE is forwarded to the PSAP in the IP network. Case 2: The INVITE is forwarded to the MGCF, as 
the PSAP resides in the PSTN. 

The E-CSCF may either forward the call to a PSAP in the IP network or forward the call to a PSAP in the PSTN. In the 
latter case the call will pass a BGCF and a MGCF before entering the PSTN. 

Upon receipt of an initial request for a dialog, or a standalone transaction, or an unknown method including a Request- 
URI with an emergency service URN in accordance with draft-ietf-ecrit-service-urn [69] or an emergency number the 
E-CSCF shall: 
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1) remove its own SIP URI from the topmost Route header; 

2) if the PS AP is the next hop, store the value of the icid parameter received in the P-Charging-Vector header and 
remove the received information in the P-Charging-Vector header, else keep the P-Charging-Vector if the next 
hop is an exit IBCF or a BGCF; 

3) if the PSAP is the next hop remove the P-Charging-Function- Addresses headers, if present, else keep the P- 
Charging-Function- Addresses headers if the next hop is an exit IBCFor an BGCF; 

4) if an IBCF or BGCF is the next hop insert a type 2 orig-ioi parameter into the P-Charging-Vector header. The E- 
CSCF shall set the type 2 orig-ioi parameter to a value that identifies the sending network. The E-CSCF shall not 
include the term-ioi parameter; 

5) get location information as 

geolocation received as a location object from a message body with the content type application/pidf+xml in 
accordance with draft-ietf-sip-location-conveyance [89]; and 

location identifier as derived from the P-Access-Network Network-Info header, if available. 

Editor's Note: The E-CSCF can also request location information from the LRF. The protocol used to retrieve the 
location information from the LRF and the external server is not decided yet. 

Editor's Note: The E-CSCF can also request location information from the external server. The address to the 
external server can be received in the Geolocation header as specified in draft-ietf-sip-location- 
conveyance [89]. The protocol used to retrieve the location information from the external server is not 
decided yet. 

6) select, based on location information and optionally type of emergency service: 

a PSAP connected to the IM CN subsystem network and add the PSAP URI to the topmost Route header; or 

NOTE 1 : The E-CSCF conveys the P- Access-Network-Info header containing the location identifier to the PSAP. 

- a PSAP in the PSTN, add the BGCF URI to the topmost Route header and add a PSAP URI in tel URI format 
to the Request-URI with an entry used in the PSTN/CS domain to address the PSAP; 

NOTE 2: The E-CSCF conveys the P-Access-Network-Info header containing the location identifier towards the 
MGCF. The MGCF can translate the location Information if included in INVITE (i.e. both the 
geolocation in PIDF-LO and the location identifier in the P-Access-Network-Info header) into ISUP 
signalling, see 3GPPTS 29.163 [IIB]. 

NOTE 3: The E-CSCF can request location information and routeing information from the LRF. The E-CSCF can 
for example send the location identifier to LRF and LRF maps the location identifier into the 
corresponding geolocation that LRF sends to E-CSCF. The LRF can invoke an RDF to convert the 
location information into a proper PSAP/EC URI. Both the location information and the PSAP URI are 
returned to the E-CSCF. 

Editor's note: The detailed protocol for converting location information into a proper PSAP/EC URI is for further 
study. Also investigate draft-hardie-ecrit-lost for its applicability. 

7) if the E-CSCF receives a reference number from the LRF the E-CSCF shall include the reference number in the 
P-Asserted-Identity header; 

NOTE 4: The reference number is used in the communication between the PSAP and LRF. 

Editor's Note: The reference number can be received from the LRF. The protocol used to retrieve the reference 
number is not decided yet. 

8) if due to local policy or if the PSAP requires interconnect functionalities (e.g. PSAP address is of an IP address 
type other than the IP address type used in the IM CN subsystem), put the address of the IBCF to the topmost 
route header, in order to forward the request to the PSAP via an IBCF in the same network; 

9) create a Record-Route header containing its own SIP URI 
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10) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the E-CSCF is able to release the session if needed; and 

ll)route the request based on SIP routeing procedures. 

Editor's Note: It needs to be investigated whether the E-CSCF also needs (under specific circumstances) to release 
an emergency session. 

NOTE 5: Depending on local operator policy, the E-CSCF has the capability to reject requests relating to specific 
methods in accordance with RFC 3261 [26], as an alternative to the functionality described above. 

Upon receipt of an initial request for a dialog, a standalone transaction, or an unknown method, that does not include a 
Request-URI with an emergency service URN or an emergency number, the E-CSCF shall reject the call by sending a 
403 (Forbidden) response. 

When the E-CSCF receives the request containing the access-network-charging-info parameter in the P-Charging- 
Vector, the E-CSCF shall store the access-network-charging-info parameter from the P-Charging- Vector header. The E- 
CSCF shall retain access-network-charging-info parameter in the P-Charging-Vector header. 

When the E-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a UE -originated dialog or standalone transaction, the E-CSCF may insert previously saved values into P- 
Charging-Vector and P-Charging-Function-Addresses headers before forwarding the message. 

When the E-CSCF receives an INVITE request from the UE, the E-CSCF may require the periodic refreshment of the 
session to avoid hung states in the E-CSCF. If the E-CSCF requires the session to be refreshed, it shall apply the 
procedures described in RFC 4028 [58] clause 8. 

NOTE 6: Requesting the session to be refreshed requires support by at least the UE or the PSAP or MGCF. This 
functionality cannot automatically be granted, i.e. at least one of the involved UAs needs to support it in 
order to make it work. 

Editor's note: The E-CSCF may be involved in the following procedures location information retrieval, routing 

information retrieval and location validation. It is still unclear where these procedures shall be specified. 



6 Application usage of SDP 

6.1 Procedures at the UE 
6.1.1 General 

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the 
precondition mechanism" and is defined in RFC 3312 [30] as updated by RFC 4032 [64]. 

In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. Hence, 
the UE shall not encrypt the SDP payloads. 

During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to modify the 
session description, or when the SDP payload must be included in the message because of SIP rules described in RFC 
3261 [26]. 

For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed bandwidth for each 
media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP. 

If the media line in the SDP indicates the usage of RTP/RTCP, and if the RTCP bandwidth level for the session is 
different than the default RTCP bandwidth as specified in RFC 3556 [56], then in addition to the "AS" bandwidth 
modifier in the media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth 
modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 [56] to specify the required 
bandwidth allocation for RTCP. 

For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will 
affect the assigned QoS which is defined in 3GPP TS 29.208 [13]. 
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NOTE 1 : In a two-party session where both participants are active, the RTCP receiver reports are not sent, 
therefore, the RR bandwidth modifer will typically get the value of zero. 

The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for audio media 
flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 2833 [23]. 

The UE shall inspect the SDP contained in any SIP request or response, looking for possible indications of grouping of 
media streams according to RFC 3524 [54] and perform the appropriate actions for IP-CAN bearer establishment for 
media according to IP-CAN specific procedures (see subclause B.2.2.5 for IP-CAN implemented using GPRS). 

If resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information 
about the media streams, media authorization and used codecs available. 

NOTE 2: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or 
receiving of the initial SDP offer. 

In order to fulfil the QoS requirements of one or more media streams, the UE may re-use previously reserved resources. 
In this case the local preconditions related to the media stream, for which resources are re-used, shall be indicated as 
met. 

If an IP-CAN bearer is rejected or modified, the UE shall, if the SDP is affected, update the remote SIP entity according 
to RFC 3261 [26] and RFC 3311 [29]. 

If the UE wants to transport media streams with TCP and there are no specific alternative negotiation mechanisms 
defined for that particular application, then the UE shall support the procedures and the SDP rules specified in 

RFC 4145 [83]. 

6.1 .2 Handling of SDP at the originating UE 

An INVITE request generated by a UE shall contain a SDP offer and at least one media description. The SDP offer 
shall reflect the calling user's terminal capabilities and user preferences for the session. The UE shall order the SDP 
offer with the most preferred codec listed first. 

If the desired QoS resources for one or more media streams have not been reserved at the UE when constructing the 
initial SDP offer, the UE shall: 

indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in 
RFC 3312 [30] and RFC 4032 [64], as well as the strength-tag value "mandatory" for the local segment and the 
strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see 
subclause 5.1.3.1); and, 

set the related media streams to inactive, by including an "a=inactive" line, according to the procedures 
described in RFC 4566 [39]. 

NOTE 1 : When setting the media streams to the inactive mode, the UE can include in the first SDP offer the proper 
values for the RS and RR modifiers and associate bandwidths to prevent the receiving of the RTCP 
packets, and not send any RTCP packets. 

If the desired QoS resources for one or more media streams are available at the UE when the initial SDP offer is sent, 
the UE shall indicate the related local preconditions as met, using the segmented status type, as defined in 
RFC 3312 [30] and RFC 4032 [64], as well as the strength-tag value "mandatory" for the local segment and the 
strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see 
subclause 5.1.3.1). 

NOTE 2: If the originating UE does not support the precondition mechanism it will not include any precondition 
information in SDP. 

Upon generating the SDP offer for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, 
as described in subclause 5.1.3.1, the UE shall include SDP payload containing a subset of the allowed media types, 
codecs and other parameters from the SDP payload of all 488 (Not Acceptable Here) responses related to the same 
session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). The UE shall 
order the codecs in the SDP payload according to the order of the codecs in the SDP payload of the 488 (Not 
Acceptable Here) response. 
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NOTE 3: The UE can attempt a session establishment through multiple networks with different policies and 

potentially can need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) 
responses from different CSCF nodes. The UE therefore takes into account the SDP contents of all the 
488 (Not Acceptable Here) responses received related to the same session establishment when building a 
new INVITE request. 

Upon confirming successful local resource reservation, the UE shall create a SDP offer in which the media streams 
previously set to inactive mode are set to active (sendrecv, sendonly or recvonly) mode. 

Upon receiving an SDP answer, which includes more than one codec for one or more media streams, the UE shall send 
an SDP offer at the first possible time, selecting only one codec per media stream. 

6.1 .3 Handling of SDP at the terminating UE 

Upon receipt of an initial SDP offer in which no precondition information is available, the terminating UE shall in the 
SDP answer: 

if, prior to sending the SDP answer the desired QoS resources have been reserved at the terminating UE, set the 
related media streams the in the SDP answer to: 

active mode, if the offered media streams were not listed as inactive; or 

inactive mode, if the offered media streams were listed as inactive. 

If the terminating UE had previously set one or more media streams to inactive mode and the QoS resources for those 
media streams are now ready, it shall set the media streams to active mode by applying the procedures described in 
RFC 4566 [39] with respect to setting the direction of media streams. 

Upon sending a SDP answer to an initial SDP offer (which included one or more media lines which was offered with 
several codecs) the terminating UE shall select exactly one codec per payload and indicate only the selected codec for 
the related media stream. 

NOTE 1: A SDP media line can indicate several different payloads. For example a media line indicating an audio 
media type can indicate several codecs for the audio stream as well as the MIME subtype "telephone- 
event" for DTMF payload. 

Upon sending a SDP answer to an initial SDP offer, with the SDP answer including one or more media streams for 
which the originating side did indicate its local preconditions as not met, if the precondition mechanism is supported by 
the terminating UE, the terminating UE shall indicate its local preconditions and request the confirmation for the result 
of the resource reservation at the originating end point. 

NOTE 2: If the terminating UE does not support the precondition mechanism it will ignore any precondition 
information received from the originating UE. 

Upon receiving an initial INVITE request, that includes the SDP offer containing an IP address type (in the "c=" 
parameter) that is not supported by the UE, it shall respond with the 488 (Not Acceptable Here) response with 301 
Warning header indicating "incompatible network address format". 

NOTE 3: Upon receiving an initial INVITE request, that includes an SDP offer containing connection addresses (in 
the "c=" parameter) equal to zero, the UE will select the media streams that is willing to accept for the 
session, reserve the QoS resources for accepted media streams, and include its valid connection address in 
the SDP answer. 

6.2 Procedures at tine P-CSCF 

When the P-CSCF receives any SIP request containing an SDP offer, the P-CSCF shall examine the media parameters 
in the received SDP. If the P-CSCF finds any media parameters which are not allowed on the network by local policy, 
the P-CSCF shall return a 488 (Not Acceptable Here) response containing SDP payload. This SDP payload contains 
either all the media types, codecs and other SDP parameters which are allowed according to the local policy, or, based 
on configuration by the operator of the P-CSCF, a subset of these allowed parameters. This subset may depend on the 
content of the received SIP request. The P-CSCF shall build the SDP payload in the 488 (Not Acceptable Here) 
response in the same manner as a UAS builds the SDP in a 488 (Not Acceptable Here) response as specifed in 
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RFC 3261 [26]. The P-CSCF shall order the SDP payload with the most preferred codec listed first. If the SDP offer is 
encrypted, the P-CSCF may reject the request. 

When the P-CSCF receives a SIP response different from 200 (OK) response containing SDP offer, the P-CSCF shall 
not examine the media parameters in the received SDP offer, but the P-CSCF shall rather check the succeeding request 
containing the SDP answer for this offer, and if necessary (i.e. the SDP answer reduced by the UE still breaches local 
policy), the P-CSCF shall return a 488 (Not Acceptable Here) response containing the local policy allowed SDP 
payload. If the SDP answer is encrypted, the P-CSCF may reject the succeeding request. 

When the P-CSCF receives a 200 (OK) response containing SDP offer, the P-CSCF shall examine the media parameters 
in the received SDP. If the P-CSCF finds any media parameters which are not allowed on the network by local policy, 
the P-CSCF shall forward the SDP offer and on the receipt of the ACK request containing the SDP answer, it shall 
immediately terminate the session as described in subclause 5.2.8.1.2. If the SDP offer is encrypted, the P-CSCF shall 
forward the SDP offer and on the receipt of the ACK request containing the SDP answer, it may immediately terminate 
the session as described in subclause 5.2.8.1.2. 

When the P-CSCF receives an initial INVITE request for a terminating session setup or a 183 (Session Progress) 
response to an INVITE request for an originating session setup, the P-CSCF may modify the SDP according to 
RFC 3524 [54] to indicate to the UE that particular media stream(s) is grouped according to a local policy. The policy is 
used to determine whether the P-CSCF will request the UE to keep media stream(s) grouped in different IP -CAN 
bearers and identify the relation between different media streams and IP-CAN bearers (see subclause B.2.2.5 for IP- 
CAN implemented using GPRS). 

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT controlled 
by the P-CSCF, or by a hosted NAT, the P-CSCF may need to modify the media connection data in SDP bodies 
according to the procedures described in annex F and/or annex G. 

The P-CSCF shall apply and maintain the same policy within the SDP from the initial request or response containing 
SDP and throughout the complete SIP session. If a media stream is added and grouping of media streams apply to the 
session, the P-CSCF shall modify the SDP according to RFC 3524 [54] to indicate to the UE that the added media 
stream(s) will be grouped into either a new group or into one of the existing groups. The P-CSCF shall not indicate re- 
grouping of media stream(s) within the SDP. 

The P-CSCF shall not apply RFC 3524 [54] to the SDP for additional media stream(s), if grouping of media stream(s) 
was not indicated in the initial INVITE request or 183 (Session Progress) response. 

The P-CSCF may inspect, if present, the "b=RS" and "b=RR" lines in order to find out the bandwidth allocation 
requirements for RTCP. 

6.3 Procedures at the S-CSCF 

When the S-CSCF receives any SIP request containing an SDP offer, the S-CSCF shall examine the media parameters 
in the received SDP. If the S-CSCF finds any media parameters which are not allowed based on local policy or 
subscription (i.e. the information in the instances of the Core Network Service Authorization class in the service profile, 
described in 3GPP TS 29.228 [14]), the S-CSCF shall return a 488 (Not Acceptable Here) response containing SDP 
payload. This SDP payload contains either all the media types, codecs and other SDP parameters which are allowed 
according to the local policy and users subscription or, based on configuration by the operator of the S-CSCF, a subset 
of these allowed parameters. This subset may depend on the content of the received SIP request. The S-CSCF shall 
build the SDP payload in the 488 (Not Acceptable Here) response in the same manner as a UAS builds the SDP in a 488 
(Not Acceptable Here) response as specified in RFC 3261 [26]. If the SDP offer is encrypted, the S-CSCF may reject 
the request. 

When the S-CSCF receives a SIP response different from 200 (OK) response containing SDP offer, the S-CSCF shall 
not examine the media parameters in the received SDP offer, but the S-CSCFshall rather check the succeeding request 
containing the SDP answer for this offer, and if necessary (i.e. the SDP answer reduced by the UE still breaches local 
policy), the S-CSCF shall return a 488 (Not Acceptable Here) response containing the local policy allowed SDP 
payload. If the SDP answer is encrypted, the S-CSCF may reject the succeeding request. 

When the S-CSCF receives a 200 (OK) response containing SDP offer, the S-CSCF shall examine the media parameters 
in the received SDP. If the S-CSCF finds any media parameters which are not allowed based on local policy or 
subscription (i.e. the information in the instances of the Core Network Service Authorization class in the service profile, 
described in 3GPP TS 29.228 [14]), the S-CSCF shall forward the SDP offer and on the receipt of the ACK request 
containing the SDP answer, it shall immediately terminate the session as described in subclause 5.4.5.1.2. If the SDP 
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offer is encrypted, the S-CSCF shall forward the SDP offer and on the receipt of the ACK request containing the SDP 
answer, it may immediately terminate the session as described in subclause 5.4.5.1.2. 

6.4 Procedures at the MGCF 

6.4.1 Calls originating from circuit-switched networks 

The usage of SDP by the MGCF is the same as its usage by the UE, as defined in the subclause 6.1 and A. 3. 2, with the 
following exception: 

in an initial SDP offer the MGCF shall not use the "inactive" attribute when the local preconditions are met; and 

in an INVITE request generated by a MGCF, the MGCF shall indicate the current status of the local 
precondition. 

When sending an SDP, the MGCF shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" descriptors in the SDP, 
and it shall ignore them when received in the SDP. 

When the MGCF generates and sends an INVITE request for a call originating in a circuit-switched network, the 
MGCF shall: 

- populate the SDP with the codecs supported by the associated MGW (see 3GPP TS 26.235 [10] for the 
supported codecs); and 

in order to support DTMF, populate the SDP with MIME subtype "telephone-event" as described in 
RFC 2833 [23]. 

When the MGCF receives 183 (Session Progress) response to an INVITE request, the MGCF shall: 

- check that a supported codec has been indicated in the SDP. 

6.4.2 Calls terminating in circuit-switched networks 

The usage of SDP by the MGCF is the same as its usage by the UE, as defined in the subclause 6.1 and A. 3. 2, with the 
following exception: 

When the MGCF sends a 183 (Session Progress) response with SDP payload, it shall only request confirmation 
for the result of the resource reservation at the originating end point if there are any remaining unfulfilled 
preconditions. 

When sending an SDP, the MGCF shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" descriptors in the SDP, 
and it shall ignore them when received in the SDP. 

When the MGCF receives an initial INVITE request, the MGCF shall: 

check for a codec that matches the requested SDP, which may include the MIME subtype "telephone-event" as 
described in RFC 2833 [23]. 

When the MGCF generates and sends a 183 (Session Progress) response to an initial INVITE request, the MGCF shall: 

set SDP indicating the selected codec, which may include the MIME subtype "telephone-event" as described in 
RFC 2833 [23]. 

6.5 Procedures at the MRFC 

Void. 

6.6 Procedures at the AS 

Since an AS may provide a wide range of different services, procedures for the SDP usage for an AS acting as 
originating UA, terminating UA or third-party call control role are dependent on the service provided to the UA and on 
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the capabilities on the remote UA. There is no special requirements regarding the usage of the SDP, except the 
requirements for the SDP capabilities described in the following paragraphs and clause A. 3: 

1) Providing that an INVITE request generated by an AS contains SDP payload, the AS has the capability of 
reflecting the originating AS's capabilities, desired QoS and precondition requirements for the session in the SDP 
payload. 

2) When the AS sends a 183 (Session Progress) response with SDP payload including one or more "m=" media 
types, it has the capability of requesting confirmation for the result of the resource reservation at the originating 
endpoint. 

6.7 Procedures at the IMS-ALG functionality 

When the IBCF acts as an IMS-ALG, it makes procedures as for an originating UA and terminating UA. The IMS-ALG 
acts as a B2BUA. The treatment of the SDP information between originating UA and terminating UA is described in 
3GPPTS 29.162 [llA]. 



7 Extensions within the present document 

7.1 SIP methods defined within the present document 

There are no SIP methods defined within the present document over and above those defined in the referenced IETF 
specifications. 

7.2 SIP headers defined within the present document 
7.2.0 General 

There are no SIP headers defined within the present document over and above those defined in the referenced IETF 
specifications. 
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7.2.1 Void 

7.2.2 Void 

7.2.3 Void 

7.2.4 Void 

7.2.5 Void 

7.2.6 Void 

7.2.7 Void 

7.2.8 Void 

7.2.9 Void 

7.2.10 Void 

7.2A Extensions to SIP iieaders defined witiiin tiie present document 
7.2A.1 Extension to WWW-authenticate header 

7.2A.1.1 Introduction 

This extension defines a new authentication parameter (auth-param) for the WWW- Authenticate header used in a 401 
(Unauthorized) response to the REGISTER request. For more information, see RFC 2617 [21] subclause 3.2.1. 

7.2A.1.2 Syntax 

The syntax for for auth-param is specified in table 7.4. 

Table 7.4: Syntax of auth-param 

auth-param = 1# ( integrity-key / cipher-key ) 

integrity-key = "ik" EQUAL ik-value 

cipher-key = "ck" EQUAL ck-value 

ik-value = LDQUOT * (HEXDIG) RDQUOT 

ck-value = LDQUOT * (HEXDIG) RDQUOT 



7.2A.1.3 Operation 

This authentication parameter will be used in a 401 (Unauthorized) response in the WWW-authenticate header during 
UE authentication procedure as specified in subclause 5.4.1. 

The S-CSCF appends the integrity-key parameter (directive) to the WWW. -Authenticate header in a 401 
(Unauthorized) response. The P-CSCF stores the integrity-key value and removes the integrity-key parameter from the 
header prior to forwarding the response to the UE. 
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The S-CSCF appends the cipher-key parameter (directive) to the WWW -Authenticate header in a 401 (Unauthorized) 
response. The P-CSCF removes the cipher-key parameter from the header prior to forwarding the response to the UE. In 
the case ciphering is used, the P-CSCF stores the cipher -key value. 

7.2A.2 Extension to Authorization Ineader 
7.2A.2.1 Introduction 

This extension defines a new auth-param for the Authorization header used in REGISTER requests. For more 
information, see RFC 2617 [21] subclause 3.2.2. 

7.2A.2.2 Syntax 

The syntax of auth-param for the Authorization header is specified in table 7.5. 

Table 7.5: Syntax of auth-param for Authorization header 

auth-param = "integrity-protected" EQUAL ("yes" / "no") 



7.2A.2.3 Operation 

This authentication parameter is inserted by the P-CSCF in the Authorization header of all the REGISTER requests 
received from the UE. The value of the "integrity protected" field in the auth-param parameter is set as specified in 
subclause 5.2.2. This information is used by S-CSCF to decide whether to challenge the REGISTER request or not, as 
specified in subclause 5.4.1. 

7.2A.3 Tokenized-by parameter definition (various Ineaders) 
7.2A.3.1 Introduction 

The tokenized-by parameter is an extension parameter appended to encrypted entries in various SIP headers as defined 
in subclause 5.10.4. 

7.2A.3.2 Syntax 

The syntax for the tokenized-by parameter is specified in table 7.6: 

Table 7.6: Syntax of tokenized-by-param 

uri-parameter = transport-param / user-param / method-param 

/ ttl-param / maddr-param / Ir-param / tokenized-by-param / other-param 

tokenized-by-param = "tokenized-by" EQUAL hostname 



The BNF for uri-parameter is taken from IETF RFC 3261 [26] and modified accordingly. 

7.2A.3.3 Operation 

The tokenized-by parameter is appended by I-CSCF(THIG) after all encrypted strings within SIP headers when network 
configuration hiding is active. The value of the parameter is the domain name of the network which encrypts the 
information. 
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7.2A.4 P-Access-Network-lnfo header 
7.2A.4.1 Introduction 

The P- Access-Network-Info header is extended to include specific information relating to particular access 
technologies. 

7.2A.4.2 Syntax 

The syntax of the P- Access-Network-Info header is described in RFC 3455 [52]. There are additional coding rules for 
this header depending on the type of IP-CAN, according to access technology specific descriptions. 

Editor's note: The appropriate usage, beyond the existing Release 5 functionality, of the P- Access-Network-Info 
header is FFS. 

Table 7.6A describes 3GPP-specific extensions to the P- Access-Network-Info header field defined in RFC 3455 [52]. 
Table 7.6A: Syntax of extensions to P-Access-Network-lnfo header 

access-type = "IEEE-802 . 11" / "IEEE-802 . 11a" / " IEEE-802 . lib" / " IEEE-802 . llg" / 

"3GPP-GERAN" / "3GPP-UTRAN-FDD" / " 3GPP-UTRAN-TDD " / "ADSL" / "ADSL2" / 
"ADSL2+" / "RADSL" / "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" / "VDSL" / 
"IDSL" / "3GPP2-1X" / "3GPP2-1X-HRPD" / "DOCSIS" / token 

access-info = cgi-3gpp / utran-cell-id-3gpp / dsl-location / i-wlan-node-id / ci-3gpp2 

/ extension-access-info 

extension-access-info = gen-value 

cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string) 

utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL (token / quoted-string) 

i-wlan-node-id = "i-wlan-node-id" EQUAL (token / quoted-string) 

dsl-location = "dsl-location" EQUAL (token / quoted-string) 

ci-3gpp2 = "ci-3gpp2" EQUAL (token / quoted-string) 



7.2A.4.3 Additional coding rules for P-Access-Network-lnfo header 

The UE shall populate the P-Access-Network-Info header, where use is specified in subclause 5.1, with the following 
contents: 

1) the access-type field set to one of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP2- 
IX", "3GPP2-1X-HRPD", "IEEE-802.H", "IEEE-802.11a", "IEEE-802. lib", "IEEE-802. llg", "ADSL", 
"ADSL2", "ADSL2H-", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", or "DOCSIS" 
as appropriate to the access technology in use. 

Editor's note: A P-CSCF generally can support more than one access network type. Where this information is 

inserted should be considered, because the end UE not always aware of the access network type. Also it 
must be clarified what would be a potential application of the access network type information. 

2) if the access type field is set to "3GPP-GERAN", a cgi-3gpp parameter set to the Cell Global Identity obtained 
from lower layers of the UE. The Cell Global Identity is a concatenation of MCC, MNC, LAC and CI (as 
described in 3GPP TS 23.003 [3]). The value of "cgi-3gpp" parameter is therefore coded as a text string as 
follows: 

Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC 
(fixed length code of 16 bits using full hexadecimal representation) and CI (fixed length code of 16 bits using 
a fall hexadecimal representation); 

3) if the access type field is equal to "3GPP-UTRAN-FDD", or "3GPP-UTRAN-TDD", a "utran-cell-id-3gpp" 
parameter set to a concatenation of the MCC, MNC, LAC (as described in 3GPP TS 23.003 [3]) and the UMTS 
Cell Identity (as described in 3GPP TS 25.331 [9 A]), obtained from lower layers of the UE, and is coded as a 
text string as follows: 

Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC 
(fixed length code of 16 bits using full hexadecimal representation) and UMTS Cell Identity (fixed length 
code of 28 bits); 
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4) if the access type field is set to "3GPP2-1X", a ci-3gpp2 parameter set to the ASCII representation of the 
hexadecimal value of the string obtained by the concatenation of SID (16 bits), NID (16 bits), PZID (8 bits) and 
BASE_ID (16 bits) (see 3GPP2 C.S0005-D [85]) in the specified order. The length of the ci-3gpp2 parameter 
shall be 14 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the 
uppercase ASCII characters. If the MS does not know the values for any of the above parameters, the MS shall 
use the value of for that parameter. For example, if the SID is unknown, the MS shall represent the SID as 
0x0000; 

NOTE 1: The SID value is represented using 16 bits as supposed to 15 bits as specified in 3GPP2 C.S0005-D [85]. 

EXAMPLE: If SID = 0x1234, NID = 0x5678, PZID = 0x12, BASE_ID = OxFFFF, the ci-3gpp2 value is set to 
the string " 12345678 12FFFF". 

5) if the access type field is set to "3GPP2-1X-HRPD", a ci-3gpp2 parameter set to the ASCII representation of the 
hexadecimal value of the string obtained by the concatenation of Sector ID (128 bits) and Subnet length (8 bits) 
(see 3GPP2 C.S0024-A [86]) in the specified order. The length of the ci-3gpp2 parameter shall be 34 
hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII 
characters; 

EXAMPLE: If the Sector ID = 0x12341234123412341234123412341234, Subnet length = 0x1 1, the ci-3gpp2 
value is set to the string "1234123412341234123412341234123411". 

6) if the access-type field set to one of "IEEE-802. 11", "IEEE-802.1 la", "IEEE-WLAN-802.1 lb" or "lEEE- 
802. 1 Ig", an "i-wlan-node-id" parameter is set to the MAC address of the AP. 

7) if the access-type field is set to one of "ADSL", "ADSL2", "ADSL2H-", "RADSL", "SDSL", "HDSL", "HDSL2", 
"G.SHDSL", "VDSL", "IDSL", the access-info field shall contain a dsl-location parameter obtained from the 
CLE (see NASS functional architecture) and derived from the binding information (IP edge ID, allocated IP 
address, line ID). The "dsl-location" is the concatenation of IP edge ID, allocated IP address, and line ID; and 

8) if the access-type field set to "DOCSIS", the access info parameter is set to a null value. This release of this 
specification does not define values for use in this parameter. 

NOTE 2: The "cgi-3gpp", the "utran-cell-id-3gpp", the "ci-3gpp2", the "i-wlan-node-id", and the "dsl-location" 
parameters described above among other usage also constitute the location identifiers that are used for 
IMS emergency services. 

Editor's note: The structure of the P-Access-Network-Info header should reflect the fact that the information is User 
Provided or Network Provided. 

7.2A.5 P-Charging-Vector header 
7.2A.5.1 Introduction 

The P-Charging- Vector header field is extended to include specific charging correlation information needed for IM CN 
subsystem functional entities. 

7.2A.5.2 Syntax 
7.2A.5.2.1 General 

The syntax of the P-Charging- Vector header field is described in RFC 3455 [52]. There may be additional coding rules 
for this header depending on the type of IP-CAN, according to access technology specific descriptions. 

Table 7.6B describes 3GPP-specific extensions to the P-Charging- Vector header field defined in RFC 3455 [52]. 
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Table 7.6B: Syntax of extensions to P-Charging-Vector header 

access-network-charging-inf o = (gprs-charging-inf o / i-wlan-charging-inf o / xdsl-charging-inf o / 

packetcable-charging-inf o / generic-param) 
gprs-charging-inf o = ggsn SEMI auth-token [SEMI pdp-inf o-hierarchy ] *(SEMI extension-param) 
ggsn = "ggsn" EQUAL gen-value 

pdp-info-hierarchy = "pdp-info" EQUAL LDQUOT pdp-info * (COMMA pdp-info) RDQUOT 
pdp-info = pdp-item SEMI pdp-sig SEMI gcid [SEMI flow-id] 
pdp-item = "pdp-item" EQUAL DIGIT 
pdp-sig = "pdp-sig" EQUAL ("yes" / "no") 
gcid = "gcid" EQUAL 1*HEXDIG 
auth-token = "auth-token" EQUAL 1*HEXDIG 
flow-id = "flow-id" EQUAL "(" "{" 1*DIGIT COMMA 1*DIGIT "}" * (COMMA "{" 1*DIGIT COMMA 1*DIGIT 

extension-param = token [EQUAL token] 

i-wlan-charging-inf o = "pdg" 

xdsl-charging-inf o = bras SEMI auth-token [SEMI xDSL-bearer-inf o] *(SEMI extension-param) 

bras = "bras" EQUAL gen-value 

xDSL-bearer-info = "dsl-bearer-inf o" EQUAL LDQUOT dsl-bearer-inf o * (COMMA dsl-bearer-inf o) RDQUOT 

dsl-bearer-info = dsl-bearer-item SEMI dsl-bearer-sig SEMI dslcid [SEMI flow-id] 

dsl-bearer-item = "dsl-bearer-item" EQUAL DIGIT 

dsl-bearer-sig = "dsl-bearer-sig" EQUAL ("yes" / "no") 

dslcid = "dslcid" EQUAL 1*HEXDIG 

packetcable-charging-inf o = packetcable [SEMI bcid] 

PacketCable = "packetcable-multimedia" 

bcid = "bcid" EQUAL 1*48(HEXDIG) 



The access-network-charging-info parameter is an instance of generic-param from the current charge-params 
component of P-Charging- Vector header. 

The access-network-charging-info parameter includes alternative definitions for different types access networks. The 
description of these parameters are given in the subsequent subclauses. 

The access network charging information is not included in the P-Charging-Vector for SIP signalling that is not 
associated with a session, 

When the access network charging information is included in the P-Charging-Vector and necessary information is not 
available from the Go/Gq interface reference points then null or zero values are included 

For type 1 and type 3 lOIs, the generating SIP entity shall express the orig-ioi and term-ioi parameters in the format of a 
quoted string as specified in RFC 3455 [52] with a specific string prefix being "Type 1" and "Type 3" respectively to 
indicate the type of lOI. For the type 2 lOI, no string prefix is used. The receiving SIP entity does not perform syntactic 
checking of the contents of the lOI parameter (the lOI parameter is passed unmodified to charging entities). 

7.2A.5.2.2 GPRS as IP-CAN 

GPRS is the initially supported access network (gprs-charging-info parameter). For GPRS there are the following 
components to track: GGSN address (ggsn parameter), media authorization token (auth token parameter), and a pdp- 
info parameter that contains the information for one or more PDP contexts. The pdp-info contains one or more pdp-item 
values followed by a collection of parameters (pdp-sig, gcid, and flow-id). The value of the pdp-item is a unique 
number that identifies each of the PDP-related charging information within the P-Charging-Vector header. Each PDP 
context has an indicator if it is an IM CN subsystem signalling PDP context (pdp-sig parameter), an associated GPRS 
Charging Identifier (gcid parameter), and a identifier (flow-id parameter). The flow-id parameter contains a sequence of 
curly bracket delimited flow identifier tuples that identify associated m-lines and relative order of port numbers in an m- 
line within the SDP from the SIP signalling to which the PDP context charging information applies. For a complete 
description of the semantics of the flow-id parameter see 3GPP TS 29.207 [12] Annex C. The gcid, ggsn address and 
flow-id parameters are transferred from the GGSN to the P-CSCF via the PDF over the Go interface (see 
3GPP TS 29.207 [12]) and Gq interface (see 3GPP TS 29.209 [13A]). 

The gcid value is received in binary format at the P-CSCF (see 3GPP TS 29.207 [12]). The P-CSCF shall encode it in 
hexadecimal format before include it into the gcid parameter. On receipt of this header, a node receiving a gcid shall 
decode from hexadecimal into binary format. 
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The access network charging information is not included in the P-Charging- Vector for SIP signalling may not be 
available for sessions that use a general purpose PDP context (for both SIP signalling and media) or that do not require 
media authorisation. 

7.2A.5.2.3 l-WLAN as IP-CAN 

The access-network-charging-info parameter is an instance of generic -param from the current charge-params 
component of P-Charging- Vector header. 

This version of the specification defines the use of "pdg" for inclusion in the P-Charging- Vector header. No other 
extensions are defined for use in I-WLAN in this version of the specification. 

7.2A.5.2.4 xDSL as IP-CAN 

The access-network-charging-info parameter is an instance of generic -param from the current charge-params 
component of P-Charging- Vector header. The access-network-charging-info parameter includes alternative definitions 
for different types of access networks. This subclause defines the components of the xDSL instance of the access- 
network-charging-info. 

For xDSL, there are the following components to track: BRAS address (bras parameter), media authorization token 
(auth-token parameter), and a set of dsl-bearer-info parameters that contains the information for one or more xDSL 
bearers. 

The dsl-bearer-info contains one or more dsl-bearer-item values followed by a collection of parameters (dsl-bearer-sig, 
dslcid, and flow-id). The value of the dsl-bearer-item is a unique number that identifies each of the dsl-bearer-related 
charging information within the P-Charging-Vector header. Each dsl-bearer-info has an indicator if it is an IM CN 
subsystem signalling dsl-bearer (dsl-bearer-sig parameter), an associated DSL Charging Identifier (dslcid parameter), 
and a identifier (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited flow 
identifier tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the 
SIP signalling to which the dsl-bearer charging information applies. For a complete description of the semantics of the 
flow-id parameter see 3GPP TS 29.207 [12] Annex C. 

The format of the dslcid parameter is identical to that of ggsn parameter. On receipt of this header, a node receiving a 
dslcid shall decode from hexadecimal into binary format. 

For a dedicated dsl-bearer for SIP signalling, i.e. no media stream requested for a session, then there is no authorisation 
activity or information exchange over the Go and Gq interfaces. Since there are no dslcid, media authorization token or 
flow identifiers in this case, the dslcid and media authorization token are set to zero and no flow identifier parameters 
are constructed by the PDF. 

7.2A.5.2.5 DOCSIS as IP-CAN 

The access-network-charging-info parameter is an instance of generic -param from the current charge-params 
component of P-Charging- Vector header. The access-network-charging-info parameter includes alternative definitions 
for different types of access networks. This subclause defines the components of the cable instance of the access- 
network-charging-info. Cable access is based upon the architecture defined by Data Over Cable Service Interface 
Specification (DOCSIS). 

The billing correlation identifier (bcid) uniquely identifies the PacketCable DOCSIS bearer resources associated with 
the session within the cable operator's network for the purposes of billing correlation. To facilitate the correlation of 
session and bearer accounting events, a correlation ID that uniquely identifies the resources associated with a session is 
needed. This is accomplished through the use of the bcid as generated by the PacketCable Multimedia network. This 
bcid is returned to the P-CSCF within the response to a successful resource request. 

The bcid is specified in RFC 3603 [74A]. This identifier is chosen to be globally unique within the system for a window 
of several months. Consistent with RFC 3603 [74A], the BCID must be encoded as a hexadecimal string of up to 48 
characters. Leading zeroes may be suppressed. 

If the bcid value is received in binary format by the P-CSCF from the IP-CAN, the P-CSCF shall encode it in 
hexadecimal format before including it into the bcid parameter. On receipt of this header, a node using a bcid will 
normally decode from hexadecimal into binary format. 
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7.2A.5.3 Operation 

The operation of this header is described in subclauses 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 and 5.8. 

7.2A.6 Orig parameter definition 
7.2A.6.1 Introduction 

The "orig" parameter is a uri-parameter intended to: 

tell the S-CSCF that it has to perform the originating services instead of terminating services; 
tell the I-CSCF that it has to perform originating procedures. 

7.2A.6.2 Syntax 

The syntax for the orig parameter is specified in table 7.7: 

Table 7.7: Syntax of orig parameter 

uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / Ir-param / 

orig / other-param 
orig = "orig" 

The BNF for uri-parameter is taken from IETF RFC 3261 [26] and modified accordingly. 

7.2A.6.3 Operation 

The orig parameter is appended to the address of the S-CSCF, I-CSCF or IBCF by the ASs, when those initiate requests 
on behalf of the user. The S-CSCF will run originating services whenever the orig parameter is present next to its 
address. The I-CSCF will run originating procedures whenever the orig parameter is present next to its address. The 
IBCF will preserve the "orig" parameter in the topmost Route header. 

7.2A.7 Extension to Security-Client, Security-Server and Security- Verify 
headers 

7.2A.7.1 Introduction 

This extension defines new paramerts for the Security-Client, Security-Server and Security- Verify headers. 

7.2A.7.2 Syntax 

The syntax for the Security-Client, Security-Server and Security- Verify headers is defined in IETF RFC 3329. The 
additional syntax is defined in Annex H of 3GPP TS 33.203 [19]. 

7.2A.7.3 Operation 

The operation of the additional parameters for the Security-Client, Security-Server and Security- Verify headers is 
defined in Annex H of 3GPP TS 33.203 [19]. 

7.2A.8 IMS Communication Service Identifier (ICSI) 
7.2A.8.1 Introduction 

The ICSI is defined to fulfil the requirements as stated in 3GPP TS 23.228 [7]. 
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7.2A.8.2 Coding of the ICSI 

This parameter is coded as a feature tag as defined in RFC 3840 [62]. 
A feature tag for an ICSI is coded with the following pattern: 

+g . ims . icsi . xxxxxx 

7.2A.9 IMS Application Reference Identifier (lARI) 
7.2A.9.1 Introduction 

The lARI is defined to fulfil the requirements as stated in 3GPP TS 23.228 [7]. 

7.2A.9.2 Coding of the lARI 

This parameter is coded as a feature tag as defined in RFC 3840 [62]. 
A feature tag for an lARJ is coded with the following pattern: 

+g . ims . iari . yyyyyy 

7.2A. 1 Phone-context parameter 
7.2A.10.1 Introduction 

The "phone-context" parameter indicates that the UE uses local service number in the Request-URI. 

7.2A.10.2 Syntax 

The syntax of the "phone-context" parameter is described in RFC 3966 [22]. There are additional coding rules for this 
parameter depending on the type of IP-CAN, according to access technology specific descriptions. 

7.2A.1 0.3 Additional coding rules for phone-context parameter 

In case the current IP-CAN is indicated in the phone-context the entities inserting the "phone-context" parameter shall 
populate the "phone-context" parameter with the following contents: 

1) if the IP-CAN is GPRS, then the "phone-context" parameter is a domain name. It is constructed from the MCC, 
the MNC and the home network domain name by concatenating the MCC, MNC, and the string "gprs" as 
domain labels before the home network domain name; 

EXAMPLE: If MCC = 216, MNC = 01, then the "phone-context" parameter is set to '216.01.gprs.homel.net'. 

2) if the IP-CAN is I-WLAN, then the "phone-context" parameter is a domain name. It is contructed from the SSID, 
AP"s MAC address, and the home network domain name by concatenating the SSID, AP"s MAC address, and 
the string "i-wlan" as domain labels before the home network domain name; 

EXAMPLE: If SSID = BU-Airport, AP"s MAC = OO-OC-Fl-12-60-28, and home network domain name is 

"homel.net", then the "phone-context" parameter is set to the string "bu-airport.OOOcfl 126028. i- 
wlan.homel.net". 

3) if the IP-CAN is xDSL, then the "phone-context" parameter is a domain name. It is contructed from the dsl- 
location (see subclause 7.2A.4) and the home network domain name by concatenating the dsl-location and the 
string "xdsl" as domain labels before the home network domain name; and 

Editor's note: The dsl-location field would need to be structured in a standardized format. This does not necessarily 
contain Geographic Location Information suitable to locate an emergency situation. 

4) if the IP-CAN is DOCSIS, then the "phone-context" parameter is a domain name. 

Editor's note: The syntax of "phone-context" parameter in case of DOCSIS access network is FFS. 
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In case the home domain is indicated in the phone-context, the "phone-context" parameter is set to the home network 
domain name (as it is used to address the SIP REGISTER request, see subclause 5. 1.1.1 A); 

In case the "phone-context" parameter indicates a network other than the home network or the visited access network, 
the "phone -context" parameter is set according to RFC 3966 [22]. 

7.3 Option-tags defined within the present document 

There are no option-tags defined within the present document over and above those defined in the referenced IETF 
specifications. 

7.4 Status-codes defined within the present document 

There are no status-codes defined within the present document over and above those defined in the referenced IETF 
specifications. 

7.5 Session description types defined within the present 
document 

There are no session description types defined within the present document over and above those defined in the 
referenced IETF specifications. 

7.6 3GPP IIVI CN subsystem XIVIL body, version 1 

7.6.1 General 

This subclause describes the Document Type Definition that is applicable for the 3GPP IM CN Subsystem XML body. 

Any SIP User Agent or proxy may insert or remove the 3GPP IM CN subsystem XML body or parts of it, as required, 
in any SIP message. The 3GPP IM CN subsystem XML body shall not be forwarded outside a 3GPP network. 

The associated MIME type with the 3GPP IMS XML body is "application/3gpp-imsH-xmr'. 

7.6.2 Document Type Definition 

The Document Type Definition, according to XML syntax definitions, is defined in table 7.7. 

Table 7.7: IM CN subsystem XML body, version 1 DTD 

<?xml version=" 1 . " ?> 

<! — Draft DTD for the IMS XML body. — > 

<!DOCTYPE ims-3gpp [ 

<! — ims-3gpp element; root element — > 

<! ELEMENT ims-3gpp ( 

alternative-service?, service-info?) > 
<!ATTLIST ims-3gpp version CDATA #REQUIRED> 

<! — service-info element; The transparent data received from HSS for AS — > 
<!ELEMENT service-info (#CDATA)> 

<! — alternative-service; alternative-service used in emergency sessions — > 

<!ELEMENT alternative-service (type, action?, reason) > 

<! ELEMENT type (emergency) > 

<!ELEMENT action (emergency-registration) > 

<! ELEMENT reason (#PCDATA)> 

]> 
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7.6.3 DTD description 

This subclause describes the elements of the IMS Document Type Definition as defined in table 7.7. 

<ims-3gpp>: This is the root element of the IMS XML body. It shall always be present. The version described 
in the present document is 1 . 

<service-info>: the transparent element received from the HSS for a particular trigger point are placed within this 
optional element. 

<alternative-service>: in the present document, the alternative service is used as a response for an attempt to 

establish an emergency session within the IM CN subsystem. The element describes an alternative 
service where the call should success. The alternative service is described by the type of service 
information. A possible reason cause why an alternative service is suggested may be included. 

The <alternative-service> element contains a <type> element that indicates the type of alternative 
service and an <action> element, an optional element. 

The <type> element contains only the value "emergency" in the present document. 

The <action> element contains only the value "emergency-registration" in the present document. 

The <reason> element contains an explanatory text with the reason why the session setup has been 
redirected. A UE may use this information to give an indication to the user. 

7.7 SIP timers 

The timers defined in RFC 3261 [26] need modification in some cases to accommodate the delays introduced by the air 
interface processing and transmission delays. Table 7.8 shows recommended values for IM CN subsystem. 

Table 7.8 lists in the first column, titled "SIP Timer" the timer names as defined in RFC 3261 [26]. 

The second column, titled "value to be applied between IM CN subsystem elements" lists the values recommended for 
network elements e.g. P-CSCF, S-CSCF, MGCF, when communicating with each other i.e. when no air interface leg is 
included. These values are identical to those recommended by RFC 3261 [26]. 

The third column, titled "value to be applied at the UE" lists the values recommended for the UE, when in normal 
operation the UE generates requests or responses containing a P- Access-Network-Info header which included a value of 
"3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP2-1X", "3GPP2-1X-HRPD", "IEEE-802.11", 
"IEEE-802.11a", "IEEE-802.11b", or "IEEE-802.11g". These are modified when compared to RFC 3261 [26] to 
accommodate the air interface delays. In all other cases, the UE should use the values specified in RFC 3261 [26] as 
indicated in the second column of table 7.8. 

The fourth column, titled "value to be applied at the P-CSCF toward a UE" lists the values recommended for the P- 
CSCF when an air interface leg is traversed, and which are used on all SIP transactions on a specific security 
association where the security association was established using a REGISTER request containing a P-Access-Network- 
Info header which included a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP2-1X", 
"3GPP2-1X-HRPD", "IEEE-802.11", "IEEE-802.11a" or "IEEE-802.11b", or "IEEE-802.11g". These are modified 
when compared to RFC 3261 [26]. In all other cases, the P-CSCF should use the values specified in RFC 3261 [26] as 
indicated in the second column of table 7.8. 

Editor's note: For WLAN, it is FFS if it is considered as a radio access or a broadband access for the recommended 
timer values. 

Editor's note: Further study is needed as to whether there are better means of determining the access technology 
delays between the P-CSCF and a UE, and therefore the conditions under which the extended values of 
the timers should apply. 

The final column reflects the timer meaning as defined in RFC 3261 [26]. 
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Table 7.8: SIP timers 



SIP Timer 


Value to be applied 

between IM CN 
subsystem elements 


Value to be 
applied at the UE 


Value to be applied at 
the P-CSCF toward a UE 


Meaning 


T1 


500ms default 


2s default 


2s default 


RTT estimate 


T2 


4s 


16s 


16s 


The maximum retransmit interval for 
non-INVITE requests and INVITE 
responses 


T4 


5s 


17s 


17s 


Maximum duration a message will 
remain in the network 


Timer A 


initially T1 


initially T1 


initially T1 


INVITE request retransmit interval, for 
UDP only 


Timer B 


64*T1 


64*T1 


64*T1 


INVITE transaction timeout timer 


Timer C 


> 3min 


> 3 min 


> 3 min 


proxy INVITE transaction timeout 


Timer D 


>32sforUDP 


>128s 


>128s 


Wait time for response retransmits 


Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 


Timer E 


initially T1 


initially T1 


initially T1 


non-INVITE request retransmit 
interval, UDP only 


Timer F 


64*T1 


64*T1 


64*T1 


non-INVITE transaction timeout timer 


Timer G 


initially T1 


initially T1 


initially T1 


INVITE response retransmit interval 


Timer H 


64*T1 


64*T1 


64*T1 


Wait time for ACK receipt. 


Timer 1 


T4 for UDP 


T4 for UDP 


T4 for UDP 


Wait time for ACK retransmits 


Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 


Timer J 


64*T1 for UDP 


64*T1 for UDP 


64''T1 for UDP 


Wait time for non-INVITE request 
retransmits 


Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 


Timer K 


T4 for UDP 


T4 for UDP 


T4 for UDP 


Wait time for response retransmits 


Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 



7.8 IM CN subsystem timers 

Table 7.9 shows recommended values for timers specific to the IM CN subsystem. 

Table 7.9: IM CN subsystem 



Timer 


Value to be 


Value to be applied at 


Value to be applied at 


Meaning 




applied at the UE 


the P-CSCF 


the S-CSCF 




reg-await- 


not applicable 


not applicable 


4 minutes 


The timer is used by the S-CSCF 


auth 








during the authentication 
procedure of the UE. For detailed 
usage of the timer see 
subclause 5.4.1.2. 
The authentication procedure 
may take in the worst case as 
long as 2 times Timer F. The IM 
CN subsystem value for Timer F 
is 128 seconds. 



NOTE: The UE and the P-CSCF use the value of the reg-await-auth timer to set the SIP level lifetime of the 
temporary set of security associations. 
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8 SIP compression 

8.1 SIP compression procedures at the UE 

8.1.1 SIP compression 

If in normal operation the UE generates requests or responses containing a P- Access-Network-Info header which 
included a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP2-1X", "3GPP2-1X- 
HRPD", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b" or "IEEE-802.11g", then the UE shall support SigComp as 
specified in RFC 3320 [32]. When using SigComp the UE shall send compressed SIP messages in accordance with 
RFC 3486 [55]. When the UE will create the compartment is implementation specific, but the compartment shall not be 
created until a set of security associations are set up. The compartment shall finish when the UE is deregistered. State 
creations and announcements shall be allowed only for messages received in a security association. 

Editor's note: For WLAN, it is FFS if it is considered as a radio access or a broadband access for the recommended 
use of compression. 

NOTE: Exchange of bytecodes during registration will prevent unnecessary delays during session setup. 

Editor's note: The draft-ietf-rohc-sigcomp-sip-01 [79] can lead to the need for additional changes or clarifications. 

If the UE supports SigComp, then the UE shall support the SIP dictionary specified in RFC 3485 [42]. If compression is 
enabled, the UE shall use the dictionary to compress the first message. 

The following apply when signalling compression is used: 

State Memory Size greater than zero is needed to give room for the UDVM byte code and make dynamic 
compression possible. A State Memory Size of at least 4096 bytes shall be a minimum value; and 

A Decompression Memory Size of at least 8192 bytes shall be a minimum value. 

8.1 .2 Compression of SIP requests and responses transmitted to the P- 
CSCF 

If in normal operation the UE generates requests or responses containing a P- Access-Network-Info header which 
included a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP2-1X", "3GPP2-1X- 
HRPD", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b" or IEEE-802.11g", then the UE should compress the 
requests and responses transmitted to the P-CSCF according to subclause 8.1.1. In other cases where SigComp is 
supported, it need not. 

Editor's note: For WLAN, it is FFS if it is considered as a radio access or a broadband access for the recommended 
use of compression. 

NOTE 1: Compression of SIP messages is an implementation option. However, compression is strongly 
recommended. 

NOTE 2: In an IP -CAN where compression support is mandatory, the UE may send even the first message 

compressed. Sigcomp provides mechanisms to allow the UE to know if state has been created in the P- 
CSCF or not. 

8.1 .3 Decompression of SIP requests and responses received from the P- 
CSCF 

If the UE supports SigComp, then theUE shall decompress the compressed requests and responses received from the P- 
CSCF according to subclause 8.1.1. 

If the UE detects a decompression failure at the P-CSCF, the recovery mechanism is implementation specific. 
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8.2 SIP compression procedures at the P-CSCF 

8.2.1 SIP compression 

The P-CSCF shall support SigComp as specified in RFC 3320 [32]. When using SigComp the P-CSCF shall send 
compressed SIP messages in accordance with RFC 3486 [55]. When the P-CSCF will create the compartment is 
implementation specific, but the compartment shall not be created until a set of security associations are set up. The 
compartment shall finish when the UE is deregistered. State creations and announcements shall be allowed only for 
messages received in a security association. 

The P-CSCF shall support the SIP dictionai-y specified in RFC 3485 [42]. If compression is enabled, the P-CSCF shall 
use the dictionary to compress the first message. 

NOTE: Exchange of bytecodes during registration will prevent unnecessary delays during session setup. 

Editor's note: The draft-ietf-rohc-sigcomp-sip-01 [79] can lead to the need for additional changes or clarifications. 

The following apply when signalling compression is used: 

State Memory Size greater than zero is needed to give room for the UDVM byte code and make dynamic 
compression possible. A State Memory Size of at least 4096 bytes shall be a minimum value; and 

A Decompression Memory Size of at least 8192 bytes shall be a minimum value. 

8.2.2 Compression of SIP requests and responses transmitted to the UE 

The P-CSCF should compress the requests and responses transmitted to the UE according to subclause 8.2.1. 

Editor's note: Further study is needed as to whether there are better means of determining the access technology 
delays between the P-CSCF and a UE, and therefore the conditions under which compression should 
apply. 

For all SIP transactions on a specific security association where the security association was established using a 
REGISTER request containing a P-Access-Network-Info header which included a value of "3GPP-GERAN","3GPP- 
UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP2-1X", "3GPP2-1X-HRPD", "IEEE-802.11", "IEEE-802.11a", "lEEE- 
802.11b" or "IEEE-802.11g" then the P-CSCF should compress the requests and responses transmitted to the UE 
according to subclause 8.2.1. In other cases where SigComp is supported, it need not. 

Editor's note: For WLAN, it is FFS if it is considered as a radio access or a broadband access for the recommended 
use of compression 

NOTE: Compression of SIP messages is an implementation option. However, compression is strongly 
recommended. 

8.2.3 Decompression of SIP requests and responses received from the 
UE 

The P-CSCF shall decompress the compressed requests and responses received from the UE according to 
subclause 8.2.1. 

If the P-CSCF detects a decompression failure at the UE, the recovery mechanism is implementation specific. 
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9 IP-Connectivity Access Network aspects when 

connected to the IIVI CN subsystem 

9.1 Introduction 

A UE accessing the IM CN subsystem and the IM CN subsystem itself utilises the services supported by the IP-CAN to 
provide packet-mode communication between the UE and the IM CN subsystem. General requirements for the UE on 
the use of these packet-mode services are specified in this clause. 

Possible aspects particular to each IP -CAN is described separately for each IP -CAN. 

9.2 Procedures at the UE 

9.2.1 Connecting to the IP-CAN and P-CSCF discovery 

Prior to communication with the IM CN subsystem, the UE shall: 

a) establish a connection with the IP -CAN; 

b) obtain an IP address using either the standard IETF protocols (e.g., DHCP or IPCP) or a protocol that is 
particular to the IP-CAN technology that the UE is utilising. The obtained IP address shall be fixed throughout 
the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the last 
deregistration; and 

c) acquire a P-CSCF address(es). 

The UE may acquire an IP address via means other than the DHCP. In this case, upon acquiring an IP address, 
the UE shall request the configuration information (that includes the DNS and P-CSCF addresses) from the 
DHCP server through a single request and reply exchanged with the DHCP server. 

The methods for acquiring a P-CSCF address(es) are: 

I. Employ Dynamic Host Configuration Protocol for IPv4 RFC 2131 [40A] or_for IPv6 (DHCPv6) 

RFC 3315 [40], the DHCP options for SIP servers RFC 3319 [41] and the DHCP options for Domain Name 
Servers (DNS) RFC 3646 [56C] in case of IPv6 and RFC 3361 [35A] in case of IPv4). 

The UE shall either: 

in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name 
Servers (DNS); or 

- request a list of SIP server IP addresses of P-CSCF(s). 

II. Obtain the P-CSCF address(es) by employing a procedure that the IP-CAN technology supports, (e.g. 
GPRS). 

When acquiring a P-CSCF address(es) the UE can freely select either method I or II. 

The UE may also request a DNS Server IP address(es) as specified in RFC 3315 [40] and RFC 3646 [56C] or 
RFC 2131 [40A]. 

9.2.2 Handling of the IP-CAN 

The UE shall ensure that appropriate resources are available for the media flow(s) on the IP-CAN(s) related to a SIP- 
session. The means to ensure this is dependant on the characteristics for each IP-CAN, and is described separately for 
each IP-CAN in question. 

GPRS is described in annex B. I-WLAN is described in annex D. xDSL is described in annex E. DOCSIS is described 
in Annex H. If a particular handling of the IP-CAN is needed for emergency calls, this is described in the annex for 
each access technology. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 1 51 ETSI TS 1 24 229 V7.6.0 (2006-1 2) 

9.2.3 Special requirements applying to forked responses 

Since the UE does not know that forking has occurred until a second provisional response arrives, the UE will request 
the radio/bearer resources as required by the first provisional response. For each subsequent provisional response that 
may be received, different alternative actions may be performed depending on the requirements in the SDP answer: 

the UE has sufficient radio/bearer resources to handle the media specified in the SDP of the subsequent 
provisional response, or 

the UE must request additional radio/bearer resources to accommodate the media specified in the SDP of the 
subsequent provisional response. 

NOTE 1 : When several forked responses are received, the resources requested by the UE is the "logical OR" of the 
resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE does 
not request more resources than proposed in the original INVITE request. 

NOTE 2: When service-based local policy is applied, the UE receives the same authorization token for all forked 
requests/responses related to the same SIP session. 

When the first final 200 (OK) response for the INVITE request is received for one of the early dialogues, the UE 
proceeds to set up the SIP session using the radio/bearer resources required for this session. Upon the reception of the 
first final 200 (OK) response for the INVITE request, the UE shall release all unneeded radio/bearer resources. 
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Annex A (normative): 

Profiles of IETF RFCs for 3GPP usage 

Editor's note: IBCF related changes not added yet. 



A.1 Profiles 

A.1 .1 Relationship to other specifications 

This annex contains a profile to the IETF specifications which are referenced by this specification, and the PICS 
proformas underlying profiles do not add requirements to the specifications they are proformas for. 

This annex provides a profile specification according to both the current IETF specifications for SIP, SDP and other 
protocols (as indicated by the "RFC status" column in the tables in this annex) which are referenced by this 
specification and to the 3GPP specifications using SIP (as indicated by the "Profile status" column in the tables in this 
annex. 

In the "RFC status" column the contents of the referenced specification takes precedence over the contents of the entry 
in the column. 

In the "Profile status" column, there are a number of differences from the "RFC status" column. Where these differences 
occur, these differences take precedence over any requirements of the IETF specifications. Where specification 
concerning these requirements exists in the main body of the present document, the main body of the present document 
takes precedence. 

Where differences occur in the "Profile status" column, the "Profile status" normally gives more strength to a "RFC 
status" and is not in contradiction with the "RFC status", e.g. it may change an optional "RFC status" to a mandatory 
"Profile status". If the "Profile status" weakens the strength of a "RFC status" then additionally this will be indicated by 
further textual description in the present document. 

For all IETF specifications that are not referenced by this document or that are not mentioned within the 3GPP profile 
of SIP and SDP, the generic rules as defined by RFC 3261 [26] and in addition the rules in clauses 5 and 6 of this 
specification apply, e.g.. 

a proxy which is built in accordance to this specification passes on any unknown method, unknown header field 
or unknown header parameter after applying procedures such as filtering, insertion of P-Asserted-Identity 
header, etc.; 

an UA which is built in accordance to this specification will 

handle received unknown methods in accordance to the procedures defined in RFC 3261 [26], e.g. respond 
with a 501 (Not Implemented) response; and 

handle unknown header fields and unknown header parameters in accordance to the procedures defined in 
RFC 3261 [26], e.g. respond with a 420 (Bad Extension) if an extension identified by an option tag in the 
Require header of the received request is not supported by the UA. 

A.1 .2 Introduction to methodology within this profile 

This subclause does not reflect dynamic conformance requirements but static ones. In particular, an condition for 
support of a PDU parameter does not reflect requirements about the syntax of the PDU (i.e. the presence of a parameter) 
but the capability of the implementation to support the parameter. 

In the sending direction, the support of a parameter means that the implementation is able to send this parameter (but it 
does not mean that the implementation always sends it). 
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In the receiving direction, it means that the implementation supports the whole semantic of the parameter that is 
described in the main part of this specification. 

As a consequence, PDU parameter tables in this subclause are not the same as the tables describing the syntax of a PDU 
in the reference specification, e.g. RFC 3261 [26] tables 2 and 3. It is not rare to see a parameter which is optional in the 
syntax but mandatory in subclause below. 

The various statii used in this subclause are in accordance with the rules in table A. 1 . 

Table A.I : Key to status codes 



Status code 


Status name 


Meaning 


m 


mandatory 


the capability shall be supported. It is a static view of the fact that the 
conformance requirements related to the capability in the reference 
specification are mandatory requirements. This does not mean that a given 
behaviour shall always be observed (this would be a dynamic view), but that it 
shall be observed when the implementation is placed in conditions where the 
conformance requirements from the reference specification compel it to do so. 
For instance, if the support for a parameter in a sent PDU is mandatory, it 
does not mean that it shall always be present, but that it shall be present 
according to the description of the behaviour in the reference specification 
(dynamic conformance requirement). 





optional 


the capability may or may not be supported. It is an implementation choice. 


n/a 


not applicable 


it is impossible to use the capability. No answer in the support column is 
required. 


X 


prohibited (excluded) 


It is not allowed to use the capability. This is more common for a profile. 


c <integer> 


conditional 


the requirement on the capability ("m", "o", "n/a" or "x") depends on the 
support of other optional or conditional items. <integer> is the identifier of the 
conditional expression. 


o.<integer> 


qualified optional 


for mutually exclusive or selectable options from a set. <integer> is the 
identifier of the group of options, and the logic of selection of the options. 


i 


irrelevant 


capability outside the scope of the given specification. Normally, this notation 
should be used in a base specification ICS proforma only for transparent 
parameters in received PDUs. However, it may be useful in other cases, when 
the base specification is in fact based on another standard. 



In the context of this specification the "i" status code mandates that the implementation does not change the content of 
the parameter. It is an implementation option if the implementation acts upon the content of the parameter (e.g. by 
setting filter criteria to known or unknown parts of parameters in order to find out the route a message has to take). 

It must be understood, that this 3GPP SIP profile does not list all parameters which an implementation will treat as 
indicated by the status code "irrelevant". In general an implementation will pass on all unknown messages, header fields 
and header parameters, as long as it can perform its normal behaviour. 

The following additional comments apply to the interpretation of the tables in this Annex. 

NOTE 1: The tables are constructed according to the conventional rules for ICS proformas and profile tables. 

NOTE 2: The notation (either directly or as part of a conditional) of "m" for the sending of a parameter and "i" for 
the receipt of the same parameter, may be taken as indicating that the parameter is passed on 
transparently, i.e. without modification. Where a conditional applies, this behaviour only applies when the 
conditional is met. 
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A.1.3 Roles 



Table A.2: Roles 



Item 


Roles 


Reference 


RFC Status 


Profile status 


1 


User agent 


[26] 


0.1 


0.1 


2 


Proxy 


[26] 


0.1 


0.1 


0.1 : It is mandatory to support exactly one of these items. 


NOTE: For the purposes of the present document it has been chosen to keep the specification simple by the tables 
specifying only one role at a time. This does not preclude implementations providing two roles, but an 
entirely separate assessment of the tables shall be made for each role. 



Table A.3: Roles specific to this profile 



Item 


Roles 


Reference 


RFC Status 


Profile status 


1 


UE 


5.1 


n/a 


0.1 


2 


P-CSCF 


5.2 


n/a 


0.1 


3 


l-CSCF 


5.3 


n/a 


0.1 


3A 


l-CSCF (THIG) 


5.3 


n/a 


Cl 


4 


S-CSCF 


5.4 


n/a 


0.1 


5 


BGCF 


5.6 


n/a 


0.1 


6 


MGCF 


5.5 


n/a 


0.1 


7 


AS 


5.7 


n/a 


0.1 


7A 


AS acting as terminating UA, or redirect 
server 


5.7.2 


n/a 


c2 


7B 


AS acting as originating UA 


5.7.3 


n/a 


c2 


7C 


AS acting as a SIP proxy 


5.7.4 


n/a 


c2 


7D 


AS performing 3rd party call control 


5.7.5 


n/a 


c2 


8 


MRFC 


5.8 


n/a 


0.1 


9 


IMS-ALG 


5.9 


n/a 


0.1 


10 


Additional routeing functionality 


Annex 1 


n/a 


c3 


11 


E-CSCF 


5.11 


n/a 


0.1 


c1 : IF A.3/3 THEN o ELSE x - - l-CSCF. 
c2: IF A.3/7 THEN 0.2 ELSE n/a - - AS. 
c3: IF A.3/3 OR A.3/4 OR A.3/5 OR A.3/6 OR A.3/9 THEN o ELSE o.l - - l-CSCF, S-CSCF, BGCF, MGCF, 

IBCF. 
0.1 : It is mandatory to support exactly one of these items. 
0.2: It is mandatory to support at least one of these items. 


NOTE: For the purposes of the present document it has been chosen to keep the specification simple by the tables 
specifying only one role at a time. This does not preclude implementations providing two roles, but an 
entirely separate assessment of the tables shall be made for each role. 
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Table A.3A: Roles specific to additional capabilities 



Item 


Roles 


Reference 


RFC Status 


Profile status 


1 


Presence server 


3GPPTS 24.141 
[8A1 


n/a 


Cl 


2 


Presence user agent 


3GPPTS 24.141 
[8A] 


n/a 


c2 


3 


Resource list server 


3GPPTS 24.141 
[8A] 


n/a 


c3 


4 


Watcher 


3GPPTS 24.141 
[8A1 


n/a 


c4 


11 


Conference focus 


3GPPTS 24.147 
[8B] 


n/a 


c5 


12 


Conference participant 


3GPPTS 24.147 
[8B] 


n/a 


c6 


21 


CSI User Agent 


3GPP TS 24.279 
[8D] 


n/a 


c7 


c1 : IF A.3/7A AND A.3/7B THEN o ELSE n/a - - AS acting as terminating UA, or redirect server and AS acting 

as originating UA. 
c2: IFA.3/1 THEN ELSE n/a-- UE. 

c3: IF A.3/7A THEN o ELSE n/a - - AS acting as terminating UA, or redirect server. 
c4: IF A.3/1 OR A.3/7B THEN o ELSE IF A.3/9 THEN m ELSE n/a - - UE or AS acting as originating UA. 
c5: IF A.3/7D AND A.3/4 AND A.3/8 THEN o ELSE n/a - - AS performing 3rd party call control and S-CSCF 

and MRFC (note 2). 
c6: IF A.3/1 OR A.3A/1 1 THEN o ELSE IF A.3/9 THEN m ELSE n/a - - UE or conference focus. 
c7: IFA.3/1 THEN ELSE n/a-- UE. 


NOTE 1 : For the purposes of the present document it has been chosen to keep the specification simple by the tables 
specifying only one role at a time. This does not preclude implementations providing two roles, but an 
entirely separate assessment of the tables shall be made for each role. 

NOTE 2: The functional split between the MRFC and the conferencing AS is out of scope of this document and they 
are assumed to be collocated. 



Table A.3B: Roles with respect to access technology 



Item 


Value used in P-Access-Network-lnfo 
header 


Reference 


RFC Status 


Profile status 


1 


3GPP-GERAN 


[52] 4.4 





cl 


2 


3GPP-UTRAN-FDD 


[521 4.4 





c1 


3 


3GPP-UTRAN-TDD 


[52] 4.4 





cl 


4 


3GPP2-1X 


[52] 4.4 





cl 


5 


3GPP2-1X-HRPD 


[52] 4.4 





cl 


11 


IEEE-802.11 


[52] 4.4 





cl 


12 


IEEE-802.11a 


[52] 4.4 





cl 


13 


IEEE-802.11b 


[52] 4.4 





cl 


14 


IEEE-802.11g 


[52] 4.4 





cl 


21 


ADSL 


[52] 4.4 





cl 


22 


ADSL2 


[52] 4.4 





cl 


23 


ADSL2-I- 


[52] 4.4 





cl 


24 


RADSL 


[52] 4.4 





cl 


25 


SDSL 


[52] 4.4 





cl 


26 


HDSL 


[52] 4.4 





cl 


27 


HDSL2 


[52] 4.4 





cl 


28 


G.SHDSL 


[52] 4.4 





cl 


29 


VDSL 


[52] 4.4 





cl 


30 


IDSL 


[52] 4.4 





cl 


41 


DOCSIS 


[52] 4.4 





cl 


cl : If A.3/1 OR A.3/2 THEN o.l ELSE n/a. 

0.1 : It is mandatory to support at least one of these items. 
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A.2 Profile definition for the Session Initiation Protocol as 
used in the present document 

A.2.1 User agent role 
A.2.1.1 Introduction 

This subclause contains the ICS proforma tables related to the user role. They need to be completed only for UA 
implementations: 

Prerequisite: A.2/1 - - user agent role. 
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A.2.1.2 Major capabilities 



Table A.4: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC Status 


Profile status 




Capabilities within main protocol 








1 


client behaviour for registration? 


[26] subclause 10.2 





c3 


2 


registrar? 


[26] subclause 10.3 





c4 


2A 


registration of multiple contacts for a 
single address of record 


[26] 10.2.1.2, 16.6 








2B 


initiating a session? 


[26] subclause 13 








2C 


initiating a session which require local 
and/or remote resource reservation? 


[27] 





c43 


3 


client behaviour for INVITE requests? 


[26] subclause 13.2 


c18 


c18 


4 


server behaviour for INVITE requests? 


[26] subclause 13.3 


c18 


c18 


5 


session release? 


[26] subclause 15.1 


c18 


c18 


6 


timestamping of requests? 


[26] subclause 8.2.6.1 








7 


authentication between UA and UA? 


[26] subclause 22.2 


c34 


c34 


8 


authentication between UA and 
registrar? 


[26] subclause 22.2 





n/a 


8A 


authentication between UA and proxy? 


[26] 20.28, 22.3 








9 


server handling of merged requests due 
to forking? 


[26] 8.2.2.2 


m 


m 


10 


client handling of multiple responses 
due to forking? 


[26] 13.2.2.4 


m 


m 


11 


insertion of date in requests and 
responses? 


[26] subclause 20.17 








12 


downloading of alerting information? 


[26] subclause 20.4 










Extensions 








13 


the SIP INFO method? 


[25] 





n/a 


14 


reliability of provisional responses in 
SIP? 


[27] 


c19 


c44 


15 


the REFER method? 


[36] 





c33 


16 


integration of resource management 
and SIP? 


[30] [64] 


c19 


c44 


17 


the SIP UPDATE method? 


[29] 


c5 


c44 


19 


SIP extensions for media authorization? 


[31] 





c14 


20 


SIP specific event notification? 


[28] 





c13 


21 


the use of NOTIFY to establish a 
dialog? 


[28] 4.2 





n/a 


22 


acting as the notifier of event 
information? 


[28] 


c2 


c15 


23 


acting as the subscriber to event 
information? 


[28] 


c2 


c16 


24 


session initiation protocol extension 
header field for registering non-adjacent 
contacts? 


[35] 





c6 


25 


private extensions to the Session 
Initiation Protocol (SIP) for network 
asserted identity within trusted 
networks? 


[34] 





m 


26 


a privacy mechanism for the Session 
Initiation Protocol (SIP)? 


[33] 





m 


26A 


request of privacy by the inclusion of a 
Privacy header indicating any privacy 
option? 


[33] 


c9 


c11 


26B 


application of privacy based on the 
received Privacy header? 


[33] 


c9 


n/a 


26C 


passing on of the Privacy header 
transparently? 


[33] 


c9 


c12 


26D 


application of the privacy option 
"header" such that those headers which 
cannot be completely expunged of 
identifying information without the 
assistance of intermediaries are 
obscured? 


[33] 5.1 


clO 


c27 
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26E 


application of the privacy option 
"session" such that anonymization for 
the session(s) initiated by this message 
occurs? 


[33] 5.2 


clO 


c27 


26F 


application of the privacy option "user" 
such that user level privacy functions 
are provided by the network? 


[33] 5.3 


clO 


c27 


26G 


application of the privacy option "id" 
such that privacy of the network 
asserted identity is provided by the 
network? 


[34] 7 


clO 


n/a 


26H 


application of the privacy option 
"history" such that privacy of the 
History-Info header is provided by the 
network? 


[66] 7.2 


c37 


c37 


27 


a messaging mechanism for the 
Session Initiation Protocol (SIP)? 


[50] 





c7 


28 


session initiation protocol extension 
header field for service route discovery 
during registration? 


[38] 





c17 


29 


compressing the session initiation 
protocol? 


[55] 





c8 


30 


private header extensions to the 
session initiation protocol for the 3rd- 
Generation Partnership Project 
(3GPP)? 


[52] 





m 


31 


the P-Associated-URI header 
extension? 


[52] 4.1 


c21 


c22 


32 


the P-Called-Party-ID header 
extension? 


[52] 4.2 


c21 


c23 


33 


the P-Visited-Network-ID header 
extension? 


[52] 4.3 


c21 


c24 


34 


the P-Access-Network-lnfo header 
extension? 


[52] 4.4 


c21 


c25 


35 


the P-Charging-Function-Addresses 
header extension? 


[52] 4.5 


c21 


c26 


36 


the P-Charging-Vector header 
extension? 


[52] 4.6 


c21 


c26 


37 


security mechanism agreement for the 
session initiation protocol? 


[48] 





c20 


38 


the Reason header field for the session 
initiation protocol? 


[34A] 





(note 1 ) 


39 


an extension to the session initiation 
protocol for symmetric response 
routeing? 


[56A] 





x 


40 


caller preferences for the session 
initiation protocol? 


[568] 


C29 


c29 


40A 


the proxy-directive within caller- 
preferences? 


[568] 9.1 


0.5 


0.5 


40B 


the cancel-directive within caller- 
preferences? 


[568] 9.1 


0.5 


0.5 


40C 


the fork-directive within caller- 
preferences? 


[568] 9.1 


0.5 


c28 


40D 


the recurse-directive within caller- 
preferences? 


[568] 9.1 


0.5 


0.5 


40E 


the parallel-directive within caller- 
preferences? 


[568] 9.1 


0.5 


c28 


40F 


the queue-directive within caller- 
preferences? 


[568] 9.1 


0.5 


0.5 


41 


an event state publication extension to 
the session initiation protocol? 


[70] 





c30 


42 


SIP session timer? 


[58] 


c19 


c19 


43 


the SIP Referred-By mechanism? 


[591 





c33 


44 


the Session Inititation Protocol (SIP) 
"Replaces" header? 


[60] 


c19 


c38 (note 1 ) 


45 


the Session Inititation Protocol (SIP) 
"Join" header? 


[61] 


c19 


c19 (note 1) 
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46 


the callee capabilities? 


[62] 





c35 


47 


an extension to the session initiation 
protocol for request history information? 


[66] 








48 


Rejecting anonymous requests in the 
session initiation protocol? 


[67] 








49 


session initiation protocol URIs for 
applications such as voicemail and 
interactive voice response 


[68] 








50 


Session Initiation Protocol's (SIP) non- 
INVITE transactions? 


[84] 


m 


m 


51 


the P-User-Database private header 
extension? 


[82] 4 








52 


a uniform resource name for services 


[69] 


n/a 


c39 


53 


obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


[93] 





c40 


54 


an extension to the session initiation 
protocol for request cpc information? 


[95] 





c41 


55 


the Stream Control Transmission 
Protocol (SCTP) as a Transport for the 
Session Initiation Protocol (SIP)? 


[96] 





c42 


56 


the SIP P-Profle-Key private header 
extension? 


[97] 


n/a 


n/a 
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c2: IF A.4/20 THEN o.1 ELSE n/a - - SIP specific event notification extension. 

c3: IF A.3/1 OR A.3/4 THEN m ELSE n/a - - UE or S-CSCF functional entity. 

c4: IF A.3/4 THEN m ELSE IF A.3/7 THEN o ELSE n/a - - S-CSCF or AS functional entity. 

c5: IF A.4/16 THEN m ELSE o - - integration of resource management and SIP extension. 

c6: IF A.3/4 OR A.3/1 THEN m ELSE n/a. - - S-CSCF or UE. 

c7: IF A.3/1 OR A.3/4 OR A.3/7A OR A.3/7B OR A.3/7D OR A.3/9 THEN m ELSE n/a - - UA or S-CSCF or AS 

acting as terminating UA or AS acting as originating UA or AS performing 3'^'' party call control or IMS-ALG. 
c8: IF A.3/1 THEN (IF (A.3B/1 OR A.3B/2 OR A.3B/3 OR A.3B/4 OR A.3B/5 OR A.3B/1 1 OR A.3B/12 OR 

A.3B/13 OR A.3B/14) THEN m ELSE o) ELSE n/a - - UE behaviour (based on P-Access-Network-lnfo 

usage). 
c9: IF A. 4/26 THEN 0.2 ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

clO: IF A.4/26B THEN 0.3 ELSE n/a - - application of privacy based on the received Privacy header. 

c1 1 : IF A.3/1 OR A.3/6 THEN o ELSE IF A.3/9 THEN m ELSE n/a - - UE or MGCF, IIVIS-ALG. 

c12: IF A.3/7D THEN m ELSE n/a - - AS performing 3rd-party call control. 

c13: IF A.3/1 OR A.3/2 OR A.3/4 OR A.3/9 THEN m ELSE o - - UE or S-CSCF or IMS-ALG. 

c14: IF A.3/1 AND A4/2B THEN m ELSE IF A.3/2 THEN o ELSE n/a - UE and initiating sessions or P-CSCF. 

c15: IF A.4/20 AND (A.3/4 OR A.3/9) THEN m ELSE o - SIP specific event notification extensions and S-CSCF, 

IMS-ALG. 
c16: IF A.4/20 AND (A.3/1 OR A.3/2 OR A.3/9) THEN m ELSE o - - SIP specific event notification extension and 

UE or P-CSCF OR IMS-ALG. 
c17: IF A.3/1 or A.3/4 THEN m ELSE n/a - - UE or S-CSCF. 

c18: IF A.4/2B THEN m ELSE n/a - - initiating sessions. 

c19: IF A.4/2B THEN o ELSE n/a - - initiating sessions. 

c20: IF A.3/1 THEN m ELSE n/a - - UE behaviour. 

c21 : IF A. 4/30 THEN 0.4 ELSE n/a - - private header extensions to the session initiation protocol for the 3rd- 

Generation Partnership Project (3GPP). 
c22: IF A.4/30 AND (A.3/1 OR A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation 

protocol for the 3rd-Generation Partnership Project (3GPP) and S-CSCF or UA. 
c23: IF A.4/30 AND A.3/1 THEN o ELSE n/a - - private header extensions to the session initiation protocol for 

the 3rd-Generation Partnership Project (3GPP) and UE. 
c24: IF A.4/30 AND A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation protocol for 

the 3rd-Generation Partnership Project (3GPP) and S-CSCF. 
c25: IF A.4/30 AND (A.3/1 OR A.3/4 OR A.3/7A OR A.3/7D OR A.3/9) THEN m ELSE n/a - - private header 

extensions to the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and UE, S- 

CSCF or AS acting as terminating UA or AS acting as third-party call controller, IMS-ALG. 
c26: IF A.4/30 AND (A.3/6 OR A.3/7A OR A.3/7B or A.3/7D) THEN m ELSE n/a - - private header extensions to 

the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and MGCF, AS acting as a 

terminating UA, or AS acting as an originating UA, or AS acting as third-party call controller. 
c27: IF A.3/7D THEN o ELSE x - - AS performing 3rd party call control. 

c28: IF A.3/1 THEN m ELSE 0.5- -UE. 

c29: IF A.4/40A OR A.4/40B OR A.4/40C OR A.4/40D OR A.4/40E OR A.4/40F THEN m ELSE n/a - - support of 

any directives within caller preferences for the session initiation protocol. 
c30: IF A.3A/1 OR A.3A/2 THEN m ELSE IF A.3/1 THEN o ELSE n/a - - presence server, presence user agent, 

UE, AS. 
c33: IF A.3/1 1 OR A.3/1 2 OR A.3/9 OR A.4/44 THEN m ELSE o - - conference focus or conference participant 

or IMS-ALG or the Session Inititation Protocol (SIP) "Replaces" header. 
c34: IF A.4/44 OR A.4/45 OR A.3/9 THEN m ELSE n/a - - the Session Inititation Protocol (SIP) "Replaces" 

header or the Session Inititation Protocol (SIP) "Join" header or IMS-ALG. 
c35: IF A.3/4 OR A.3/9 OR A.3A/21 THEN m ELSE IF (A.3/1 OR A.3/6 OR A.3/7 OR A.3/8) THEN o ELSE n/a - 

- S-CSCF or IMS-ALG functional entities, UE or MGCF or AS or MRFC functional entity. 
c37 IF A. 4/47 THEN 0.3 ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
c38: IF A.4/2B AND (A.3A/1 1 or A.3A/12) THEN m ELSE IF A.4/2B THEN o ELSE n/a - - initiating sessions, 

conference focus, conference participant. 
c39: IF A.3/1 THEN m ELSE n/a-- UE. 

c40 IF A.3/4 THEN m ELSE IF (A.3/1 OR A.3/7A OR A.3/7B OR A.3/7D) THEN o ELSE n/a - - S-CSCF, UE, 

AS, AS acting as terminating UA, or redirect server, AS acting as originating UA, AS performing 3rd party 

call control. 
c41 : IF A.3/2 OR A.3/3 OR A.3/4 OR A.3.5 OR A.3/6 OR A.3/7 OR A.3/8 THEN o ELSE n/a - - cpc URI 

parameter. 
c42: IF A.3/1 n/a ELSE o -- UE. 

c43: IF A.4/2B THEN o ELSE n/a - - initiating sessions. 

c44: IF A.4/2C THEN m ELSE o - - initiating a session which require local and/or remote resource reservation. 
0.1 : At least one of these capabilities is supported. 
0.2: At least one of these capabilities is supported. 
0.3: At least one of these capabilities is supported. 
0.4: At least one of these capabilities is supported. 
0.5: At least one of these capabilities is supported. 
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NOTE 1 : At the MGCF, the interworking specifications do not support a handling of the header associated with this 
extension. 



Editor's note: For WLAN, it is FFS if it is considered as a radio access or a broadband access for the recommended 
use of compression 

Prerequisite A.5/20 - - SIP specific event notification 

Table A.4A: Supported event packages 



Item 


Does the implementation 
support 


Subscriber 


Notifier 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


reg event package? 


[43] 


c1 


c3 


[43] 


c2 


c4 


1A 


reg event package extension 
for GRUUs? 


[94] 


Cl 


c25 


[94] 


c2 


c4 


2 


refer package? 


[36] 3 


c13 


c13 


[36] 3 


c13 


c13 


3 


presence package? 


[7416 


cl 


c5 


[7416 


c2 


c6 


4 


eventlist with underlying 
presence package? 


[75], [74] 
6 


cl 


c7 


[75], [74] 
6 


c2 


c8 


5 


presence.winfo template- 
package? 


[72] 4 


cl 


c9 


[72] 4 


c2 


clO 


6 


ua-profile package? 


[7713 


cl 


c11 


[7713 


c2 


c12 


7 


conference package? 


[7813 


cl 


c21 


[7813 


cl 


c22 


8 


message-summary package? 


[65] 


cl 


c23 


[65] 3 


c2 


c24 


c1 : IF A. 4/23 THEN o ELSE n/a - - acting as the subscriber to event information. 

c2: IF A.4/22 THEN o ELSE n/a - - acting as the notifier of event information. 

c3: IF A.3/1 OR A.3/2 THEN m ELSE IF A.3/7 THEN o ELSE n/a - - UE, P-CSCF, AS. 

c4: IF A.3/4 THEN m ELSE n/a - - S-CSCF. 

c5: IF A.3A/3 OR A.3A/4 THEN m ELSE IF A.4/23 THEN o ELSE n/a - - resource list server or watcher, acting 

as the subscriber to event information. 
c6: IF A.3A/1 THEN m ELSE IF A.4/22 THEN o ELSE n/a - - presence server, acting as the notifier of event 

information. 
c7: IF A.3A/4 THEN m ELSE IF A.4/23 THEN o ELSE n/a - - watcher, acting as the subscriber to event 

information. 
c8: IF A.3A/3 THEN m ELSE IF A.4/22 THEN o ELSE n/a - - resource list server, acting as the notifier of event 

information. 
c9: IF A.3A/2 THEN m ELSE IF A.4/23 THEN o ELSE n/a - - presence user agent, acting as the subscriber to 

event information. 
c10: IF A.3A/1 THEN m ELSE IF A.4/22 THEN o ELSE n/a - - presence server, acting as the notifier of event 

information. 
c1 1 : IF A.3A/2 OR A.3A/4 THEN o ELSE IF A.4/23 THEN o ELSE n/a - - presence user agent or watcher, acting 

as the subscriber to event information. 
c12: IF A.3A/1 OR A.3A/3 THEN m ELSE IF A.4/22 THEN o ELSE n/a - - presence server or resource list 

server, acting as the notifier of event information. 
c13: IF A.4/15 THEN m ELSE n/a - - the REFER method. 
c21 : IF A.3A/12 THEN m ELSE IF A.4/23 THEN o ELSE n/a - - conference participant or acting as the 

subscriber to event information. 
c22: IF A.3A/1 1 THEN m ELSE IF A.4/22 THEN o ELSE n/a - - conference focus or acting as the notifier of 

event information. 
c23: IF (A.3/1 OR A.3/7A OR A.3/7B) AND A.4/23 THEN o ELSE n/a - - UE, AS acting as terminating UA, or 

redirect server, AS acting as originating UA all as subscriber of event information. 
c24: IF (A.3/1 OR A.3/7A OR A.3/7B) AND A.4/22 THEN o ELSE n/a - - UE, AS acting as terminating UA, or 

redirect server, AS acting as originating UA all as notifier of event information. 
c25: IF A.4A/1 THEN (IF A.3/1 AND A.4/53 THEN m ELSE o) ELSE n/a - - reg event package, UE, reg event 

package extension for GRUUs. 
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A.2.1.3 PDUs 



Table A.5: Supported methods 



Item 


PDU 


Sending 


Receiving 




Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


ACK request 


[26] 13 


c10 


clO 


[26)13 


c11 


oil 


2 


BYE request 


[26] 15.1 


c12 


c12 


[26) 15.1 


c12 


c12 


3 


BYE response 


[26] 15.1 


c12 


c12 


[26)15.1 


c12 


c12 


4 


CANCEL request 


[2619 


m 


m 


[26)9 


m 


m 


5 


CANCEL response 


[26)9 


m 


m 


[26)9 


m 


m 


8 


INVITE request 


[26] 13 


c10 


ClO 


[26)13 


c11 


oil 


9 


INVITE response 


[26] 13 


oil 


oil 


[26) 13 


c10 


ClO 


9A 


MESSAGE request 


[50] 4 


c7 


c7 


[50)7 


c7 


c7 


9B 


MESSAGE response 


[5014 


c7 


c7 


[5017 


c7 


c7 


10 


NOTIFY request 


[28)8.1.2 


c4 


c4 


[28)8.1.2 


c3 


c3 


11 


NOTIFY response 


[28)8.1.2 


c3 


c3 


[28)8.1.2 


c4 


c4 


12 


OPTIONS request 


[26] 1 1 


m 


m 


[26] 1 1 


m 


m 


13 


OPTIONS response 


[26] 1 1 


m 


m 


[26] 1 1 


m 


m 


14 


PRACK request 


[2716 


c5 


c5 


[27)6 


c5 


c5 


15 


PRACK response 


[27)6 


c5 


c5 


[2716 


c5 


c5 


15A 


PUBLISH request 


[70) 
11.1.3 


c20 


c20 


[70] 
11.1.3 


c20 


c20 


15B 


PUBLISH response 


[70) 
11.1.3 


c20 


c20 


[70] 
11.1.3 


c20 


c20 


16 


REFER request 


[36] 3 


c1 


cl 


[36)3 


c1 


cl 


17 


REFER response 


[36)3 


Cl 


cl 


[36)3 


c1 


cl 


18 


REGISTER request 


[26) 10 


c8 


c8 


[26] 10 


c9 


c9 


19 


REGISTER response 


[26)10 


c9 


c9 


[26] 10 


c8 


c8 


20 


SUBSCRIBE request 


[2818.1.1 


c3 


c3 


[2818.1.1 


c4 


c4 


21 


SUBSCRIBE response 


[2818.1.1 


c4 


c4 


[28)8.1.1 


c3 


c3 


22 


UPDATE request 


[29) 6.1 


c6 


c6 


[29) 6.2 


c6 


c6 


23 


UPDATE response 


[29) 6.2 


c6 


c6 


[29) 6.1 


c6 


c6 


c1: 
c3: 
c4: 
c5: 
c6: 
c7: 
c8: 
c9: 
clO 
c11 
c12 
c20 


IF A.4/15 THEN m ELSE n/a - - the REFER method extension. 

IF A.4/23 THEN m ELSE n/a - - recipient for event information. 

IF A.4/22 THEN m ELSE n/a - - notifier of event information. 

IF A.4/14 THEN m ELSE n/a - - reliability of provisional responses extension. 

IF A.4/17 THEN m ELSE n/a - - the SIP update method extension. 

IF A.4/27 THEN m ELSE n/a - - the SIP MESSAGE method. 

IF A.4/1 THEN m ELSE n/a - - client behaviour for registration. 

IF A.4/2 THEN m ELSE n/a - - registrar. 

IF A.4/3 THEN m ELSE n/a - - client behaviour for INVITE requests. 

IF A. 4/4 THEN m ELSE n/a - - server behaviour for INVITE requests. 

IF A. 4/5 THEN m ELSE n/a - - session release. 

IFA.4/41 THENm ELSE n/a. 
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A.2.1.4 PDU parameters 



A.2.1.4.1 



Status-codes 



Table A.6: Supported status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


100 (Trying) 


[26] 21.1.1 


c21 


c21 


[26] 21.1.1 


c11 


c11 


101 


Ixx response 


[26] 21.1 


p21 


p21 


[26] 21.1 


p21 


p21 


2 


180 (Ringing) 


[26)21.1.2 


c2 


c2 


[26] 21.1.2 


c1 


cl 


3 


181 (Call Is Being 
Forwarded) 


[26] 21.1.3 


c2 


c2 


[26] 21.1.3 


c1 


cl 


4 


182 (Queued) 


[26] 21.1.4 


c2 


c2 


[26] 21.1.4 


c1 


cl 


5 


183 (Session Progress) 


[26] 21.1.5 


Cl 


cl 


[26] 21.1.5 


c1 


cl 


102 


2xx response 


[26] 21 .2 


p22 


p22 


[26] 21.1 


p22 


p22 


6 


200 (OK) 


[26] 21.2.1 


m 


m 


[26] 21.2.1 


m 


m 


7 


202 (Accepted) 


[28] 8.3.1 


c3 


c3 


[28] 8.3.1 


c3 


c3 


103 


3xx response 


[26] 21 .3 


p23 


p23 


[26] 21.1 


p23 


p23 


8 


300 (IVIultiple Choices) 


[26] 21 .3.1 






[26] 21 .3.1 






9 


301 (Moved Permanently) 


[26] 21 .3.2 






[26] 21 .3.2 






10 


302 (IVIoved Temporarily) 


[26] 21 .3.3 






[26] 21 .3.3 






11 


305 (Use Proxy) 


[26] 21 .3.4 






[26] 21 .3.4 






12 


380 (Alternative Service) 


[26] 21 .3.5 






[26] 21 .3.5 






104 


4xx response 


[26] 21 .4 


p24 


p24 


[26] 21 .4 


p24 


p24 


13 


400 (Bad Request) 


[26] 21.4.1 


m 


m 


[26] 21.4.1 


m 


m 


14 


401 (Unauthorized) 


[26] 21 .4.2 





c12 


[26] 21 .4.2 


m 


m 


15 


402 (Payment Required) 


[26] 21 .4.3 


n/a 


n/a 


[26] 21 .4.3 


n/a 


n/a 


16 


403 (Forbidden) 


[26] 21 .4.4 


m 


m 


[26] 21 .4.4 


m 


m 


17 


404 (Not Found) 


[26] 21.4.5 


m 


m 


[26] 21 .4.5 


m 


m 


18 


405 (IVIethod Not Allowed) 


[26] 21 .4.6 


m 


m 


[26] 21 .4.6 


m 


m 


19 


406 (Not Acceptable) 


[26] 21 .4.7 


m 


m 


[26] 21 .4.7 


m 


m 


20 


407 (Proxy Authentication 
Required) 


[26] 21 .4.8 








[26] 21 .4.8 


m 


m 


21 


408 (Request Timeout) 


[26] 21 .4.9 


c2 


c2 


[26] 21 .4.9 


m 


m 


22 


410 (Gone) 


[26] 21 .4.10 


m 


m 


[26] 21 .4.10 


m 


m 


22A 


412 (Conditional Request 
Failed) 


[70] 11.2.1 


c20 


c20 


[70] 11.2.1 


c20 


c20 


23 


413 (Request Entity Too 
Large) 


[26] 21 .4.11 


m 


m 


[26] 21 .4.11 


m 


m 


24 


414(Request-URIToo 
Large) 


[26] 21 .4.1 2 


m 


m 


[26] 21 .4.1 2 


m 


m 


25 


415 (Unsupported IVIedia 
Type) 


[26] 21 .4.1 3 


m 


m 


[26] 21 .4.1 3 


m 


m 


26 


416 (Unsupported URI 
Scheme) 


[26] 21 .4.1 4 


m 


m 


[26] 21 .4.1 4 


m 


m 


27 


420 (Bad Extension) 


[26] 21.4.15 


m 


c13 


[26] 21 .4.1 5 


m 


m 


28 


421 (Extension Required) 


[26] 21 .4.1 6 







[26] 21 .4.1 6 


i 


i 


28A 


422 (Session Interval Too 
Small) 


[58] 6 


c7 


c7 


[58] 6 


c7 


c7 


29 


423 (interval Too Brief) 


[26] 21 .4.1 7 


c4 


c4 


[26] 21.4.17 


m 


m 


29A 


429 (Provide Referrer 
Identity) 


[59] 5 


c8 


c8 


[59] 5 


c9 


c9 


29B 


433 (Anonymity 
Disallowed) 


[67] 4 


c14 


c14 


[67] 4 


c14 


c14 


30 


480 (Temporarily 
Unavailable) 


[26] 21 .4.1 8 


m 


m 


[26] 21 .4.1 8 


m 


m 


31 


481 (Call/Transaction 
Does Not Exist) 


[26] 21 .4.1 9 


m 


m 


[26] 21 .4.1 9 


m 


m 


32 


482 (Loop Detected) 


[26] 21.4.20 


m 


m 


[26] 21 .4.20 


m 


m 


33 


483 (Too IVIany Hops) 


[26] 21 .4.21 


m 


m 


[26] 21 .4.21 


m 


m 


34 


484 (Address Incomplete) 


[26] 21 .4.22 








[26] 21 .4.22 


m 


m 


35 


485 (Ambiguous) 


[26] 21 .4.23 








[26] 21 .4.23 


m 


m 


36 


486 (Busy Here) 


[26] 21.4.24 


m 


m 


[26] 21.4.24 


m 


m 
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Item 


Header 


Sending 


Receiving 




Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


37 


487 (Request Terminated) 


[26] 21 .4.25 


m 


m 


[26)21.4.25 


m 


m 


38 


488 (Not Acceptable Here) 


[26] 21.4.26 


m 


m 


[26)21.4.26 


m 


m 


39 


489 (Bad Event) 


[28] 7.3.2 


c3 


c3 


[28) 7.3.2 


c3 


c3 


40 


491 (Request Pending) 


[26] 21.4.27 


m 


m 


[26)21.4.27 


m 


m 


41 


493 (Undecipherable) 


[26] 21 .4.28 


m 


m 


[26)21.4.28 


m 


m 


41A 


494 (Security Agreement 
Required) 


[48)2 


c5 


c5 


[48)2 


c6 


c6 


105 


5xx response 


[26] 21 .5 


p25 


p25 


[26)21.5 


p25 


p25 


42 


500 (Internal Server Error) 


[26] 21 .5.1 


m 


m 


[26)21.5.1 


m 


m 


43 


501 (Not Implemented) 


[26] 21 .5.2 


m 


m 


[26)21.5.2 


m 


m 


44 


502 (Bad Gateway) 


[26] 21 .5.3 








[26)21.5.3 


m 


m 


45 


503 (Service Unavailable) 


[26] 21.5.4 


m 


m 


[26)21.5.4 


m 


m 


46 


504 (Server Time-out) 


[26] 21.5.5 


m 


m 


[26)21.5.5 


m 


m 


47 


505 (Version not 
supported) 


[26)21.5.6 


m 


m 


[26)21.5.6 


m 


m 


48 


513 (IVIessage Too Large) 


[26)21.5.7 


m 


m 


[26)21.5.7 


m 


m 


49 


580 (Precondition Failure) 


[30)8 






[30)8 






106 


6xx response 


[26] 21 .6 


p26 


p26 


[26)21.6 


p26 


p26 


50 


600 (Busy Everywhere) 


[26)21.6.1 


m 


m 


[26)21.6.1 


m 


m 


51 


603 (Decline) 


[26)21.6.2 


clO 


ClO 


[26)21.6.2 


m 


m 


52 


604 (Does Not Exist 
Anywhere) 


[26)21.6.3 


m 


m 


[26)21.6.3 


m 


m 


53 


606 (Not Acceptable) 


[26)21.6.4 


m 


m 


[26)21.6.4 


m 


m 


c1: 
c2: 
c3: 
c4: 
c5: 

c6: 
c7: 

c8: 
c9: 
clO 
c11 

c12 
c13 
c14 
c20 
c21 

p21 
p22 
p23 
p24 

p25 
p26 


IF A.5/9 THEN m ELSE n/a - - INVITE response. 

IF A.5/9 THEN o ELSE n/a - - INVITE response. 

IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.5/19 OR A.5/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE response. 

IF A.4/37 AND A. 4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 

and registrar. 

IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

IF A.4/42 AND (A.5/9 OR A.5/23) THEN m ELSE n/a - - the SIP session timer AND (INVITE response OR 

UPDATE response). 

IF A.4/43 AND A.5/17 THEN o ELSE n/a - - the SIP Referred-By mechanism and REFER response. 

IF A.4/43 AND A.5/17 THEN m ELSE n/a - - the SIP Referred-By mechanism and REFER response. 

IF A.4/44 THEN m ELSE o - - the Session Inititation Protocol (SIP) "Replaces" header. 

IF A.5/3 OR A.5/9 OR A.5/9B OR A.5/1 1 0R A.5/1 3 OR A.5/1 5 OR A.5/1 5B OR A.5/1 7 OR A.5/1 9 OR 

A.5/21 OR A.5/23 THEN m ELSE n/a - - BYE response or INVITE response or IVIESSAGE response or 

NOTIFY response or OPTIONS response or PRACK response or PUBLISH response or REFER response 

or REGISTER response or SUBSCRIBE response or UPDATE response. 

IF A.3/4 THEN m ELSE o - - S-CSCF. 

IF A.3/1 OR A.3/2 OR A.3/4 THEN m ELSE o - - UE, P-CSCF, S-CSCF. 

IF A.4/48 THEN m ELSE n/a - - rejecting anonymous requests in the session initiation protocol. 

IF A.4/41 THEN m ELSE n/a - - an event state publication extension to the session initiation protocol. 

IF A.5/3 OR A.5/9 OR A.5/9B OR A.5/1 1 or A.5/1 3 OR A.5/1 5 OR A.5/1 5B OR A.5/17 OR A.5/19 OR A.5/21 

OR A.5/23 THEN o ELSE n/a - - BYE response or INVITE response or MESSAGE response or NOTIFY 

response or OPTIONS response or PRACK response or PUBLISH response or REFER response or 

REGISTER response or SUBSCRIBE response or UPDATE response. 

A.6/2 OR A.6/3 OR A.6/4 OR A.6/5 - - Ixx response. 

A. 6/6 OR A.6/7 - - 2xx response. 

A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.8/13 - - 3xx response. 

A.6/14 OR A.6/15 OR A.6/16 OR A.6/17 OR A.6/18 OR A.6/19 OR A.6/20 OR A.6/21 OR A.6/22 OR 

A.6/22A OR A.6/23 OR A.6/24 OR A.6/25 OR A.6/26 OR A.6/27 OR A.6/28 OR A.6/28A OR A.6/29 OR 

A.6/29A OR A.6/29B OR A.6/30 OR A.6/31 OR A.6/32 OR A.6/33 OR A.6/34 OR A.6/35 OR A.6/36 OR 

A.6/436 OR A.6/38 OR A.6/39 OR A.6/40 OR A.6/41 OR A.6/41A. - 4xx response. 

A.6/42 OR A.6/43 OR A.6/44 OR A.6/45 OR A.6/46 OR A.6/47 OR A.6/48 OR A.6/49 - - 5xx response 

A.6/50 OR A.6/51 OR A.6/52 OR A.6/53 - - 6xx response. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 

A.2.1.4.2 ACK method 

Prerequisite A.5/1 - ACK request 



165 



ETSI TS 124 229 V7.6.0 (2006-12) 



Table A.7: Supported headers within the ACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept-Contact 


[56B] 9.2 


c9 


c9 


[56B) 9.2 


c10 


ClO 


2 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28) 7.2.2 


c2 


c2 


3 


Authorization 


[26] 20.7 


c3 


c3 


[26) 20.7 


c3 


c3 


4 


Call-ID 


[26] 20.8 


m 


m 


[26) 20.8 


m 


m 


6 


Content-Disposition 


[26)20.11 








[26)20.11 


m 


m 


7 


Content-Encoding 


[26)20.12 








[26)20.12 


m 


m 


8 


Content-Language 


[26)20.13 








[26)20.13 


m 


m 


9 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


10 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


m 


m 


11 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


12 


Date 


[26)20.17 


c4 


c4 


[26)20.17 


m 


m 


13 


From 


[26) 20.20 


m 


m 


[26) 20.20 


m 


m 


14 


IVIax-Forwards 


[26) 20.22 


m 


m 


[26) 20.22 


n/a 


n/a 


15 


MIME-Version 


[26) 20.24 








[26) 20.24 


m 


m 


15A 


Privacy 


[33) 4.2 


c6 


n/a 


[33) 4.2 


c6 


n/a 


16 


Proxy-Authorization 


[26) 20.28 


c5 


c5 


[26) 20.28 


n/a 


n/a 


17 


Proxy-Require 


[26) 20.29 





n/a 


[26) 20.29 


n/a 


n/a 


17A 


Reason 


[34A) 2 


c8 


c8 


[34A) 2 


c8 


c8 


17B 


Reject-Contact 


[56B) 9.2 


c9 


c9 


[56B) 9.2 


c10 


ClO 


17C 


Request-Disposition 


[568) 9.1 


c9 


c9 


[568) 9.1 


clO 


ClO 


18 


Require 


[26) 20.32 








[26) 20.32 


m 


m 


19 


Route 


[26) 20.34 


m 


m 


(26) 20.34 


n/a 


n/a 


20 


Timestamp 


(26) 20.38 


c7 


c7 


[26) 20.38 


m 


m 


21 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


22 


User-Agent 


[26) 20.41 








[26) 20.41 


m 


m 


23 


Via 


[26) 20.42 


m 


m 


[26) 20.42 


m 


m 


c1 : IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

c2: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

c3: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

c4: IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c5: IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

c6: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

c8: IF A.4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 

c9: IF A. 4/40 THEN o ELSE n/a - - caller preferences for the session initiation protocol. 

clO: IF A.4/40 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 



Editor's note: Is the following table a suitable way of showing the contents of message bodies. 
Prerequisite A.5/1 - ACK request 

Table A.8: Supported message bodies within the ACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.3 BYE method 

Prerequisite A.5/2 - - BYE request 



Table A.9: Supported headers within the BYE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Contact 


[56B] 9.2 


c18 


c18 


[56B] 9.2 


c22 


c22 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


c1 


[28] 7.2.2 


c2 


c2 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


16 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c9 


clO 


[52] 4.4 


c9 


oil 


16B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c6 


c6 


16C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c13 


c14 


[52] 4.5 


c13 


c14 


16D 


P-Charging-Vector 


[52] 4.6 


c12 


n/a 


[52] 4.6 


c12 


n/a 


16E 


P-Preferred-ldentity 


[34] 9.2 


c6 


X 


[34] 9.2 


n/a 


n/a 


16F 


Privacy 


[33] 4.2 


c7 


n/a 


[33] 4.2 


c7 


c7 


17 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


18 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


18A 


Reason 


[34A] 2 


c17 


c21 


[34A] 2 


c17 


c17 


19 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


19A 


Referred-By 


[59] 3 


c19 


c19 


[59] 3 


c20 


c20 


19B 


Reject-Contact 


[56B] 9.2 


c18 


c18 


[56B] 9.2 


c22 


c22 


19C 


Request-Disposition 


[56B] 9.1 


c18 


c18 


[56B] 9.1 


c22 


c22 


20 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


21 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


21A 


Security-Client 


[48] 2.3.1 


c15 


c15 


[48] 2.3.1 


n/a 


n/a 


21 B 


Security-Verify 


[48] 2.3.1 


c16 


c16 


[48] 2.3.1 


n/a 


n/a 


22 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


23 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


24 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


25 


User-Agent 


[26] 20.41 








[26] 20.41 








26 


Via 


[26] 20.42 


m 


m 


[20] 20.42 


m 


m 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



167 



ETSI TS 124 229 V7.6.0 (2006-12) 



c1: 
c2: 
c3: 
c4: 
c5: 
c6: 

c7: 

c8: 

c9: 

c10: 

c11: 

c12 
c13 
c14 
c15 
c16 
c17 
c18 
c19 
c20 
c21 

c22: 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and AS 

acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note). 

- security mechanism agreement for the session initiation protocol. 

- the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 
P-CSCF, the Reason header field for the session 



IFA.4/35THENm ELSE n/a ■ 

IF A.4/37 THEN ELSE n/a - 

IFA.4/37THENm ELSE n/a • 

IF A.4/38 THEN ELSE n/a - 

IF A.4/40 THEN ELSE n/a - 

IF A.4/43 THEN m ELSE n/a ■ 

IF A.4/43 THEN ELSE n/a - 

IF A.3/2 THEN m ELSE IF A.4/38 THEN o ELSE n/a 

initiation protocol. 

IF A.4/40 THEN m ELSE n/a - - caller preferences for the session initiation protocol 



NOTE: Support of this header in this method is dependent on the security mechanism and the security architecture which 

is implemented. Use of this header in this method is not appropriate to the security mechanism defined by 
3GPPTS 33.203 [19]. 



Prerequisite A.5/2 - - BYE request 

Table A.10: Supported message bodies within the BYE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Table A.11: Void 

Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.11 A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


cl 


[26)20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
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Prerequisite A.5/3 - - BYE response for all status-codes 



Table A.12: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


oil 


oil 


[26] 20.5 


m 


m 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26120.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c6 


10B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


10C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


clO 


[52] 4.5 


c9 


ClO 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


n/a 


[52] 4.6 


c8 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10F 


Privacy 


[33] 4.2 


c4 


n/a 


[33] 4.2 


c4 


c4 


10G 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


10H 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 


(note) 


[26] 20.43 








c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
c4: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
clO: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.6/1 8 THEN m ELSE o - - 405 (Method Not Allowed) 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 



Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/102 - - Additional for 2xx response 



Table A.13: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


c3 


c3 


[28] 7.2.2 


c4 


c4 


1 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


4 


Supported 


[26] 20.37 





m 


[26] 20.37 


m 


m 


cl : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
c3: IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
c4: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
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Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.13A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/103 OR A. 6/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.14: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OB 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


NOTE: RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 



Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/14 - - Additional for 401 (Unauthorized) response 



Table A.15: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


cl 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.16: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.1 7: Void 

Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/19 - - Additional for 407 (Proxy Authentication Required) response 

Table A.1 8: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Proxy-Autlienticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


c1 


c1 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/3 - - BYE response 

Prerequisite A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.19: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.20: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.20A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


Cl 


cl 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 
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Table A.21 : Void 

Prerequisite A.5/3 - - BYE response 

Table A.22: Supported message bodies within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.2.1.4.4 CANCEL method 

Prerequisite A.5/4 - - CANCEL request 



Table A.23: Supported headers within the CANCEL request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept-Contact 


[56B1 9.2 


c9 


c9 


[568] 9.2 


c11 


oil 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26) 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


9 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


10 


Date 


[26)20.17 


c4 


c4 


[26)20.17 


m 


m 


11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


12 


IVIax-Forwards 


[26) 20.22 


m 


m 


[26) 20.22 


n/a 


n/a 


14 


Privacy 


[33) 4.2 


c6 


n/a 


[33) 4.2 


c6 


n/a 


15 


Reason 


[34A) 2 


c7 


clO 


[34A) 2 


c7 


c7 


16 


Record-Route 


[26) 20.30 


n/a 


n/a 


[26) 20.30 


n/a 


n/a 


17 


Reject-Contact 


[56B] 9.2 


c9 


c9 


[56B) 9.2 


c11 


oil 


17A 


Request-Disposition 


[56B] 9.1 


c9 


c9 


[56B] 9.1 


c11 


oil 


18 


Route 


[26) 20.34 


m 


m 


(26) 20.34 


n/a 


n/a 


19 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


20 


Timestamp 


(26) 20.38 


c8 


c8 


[26) 20.38 


m 


m 


21 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


22 


User-Agent 


[26] 20.41 







[26) 20.41 







23 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c3: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

c4: IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c6: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A. 4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 

c8: IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

c9: IF A. 4/40 THEN o ELSE n/a - - caller preferences for the session initiation protocol. 

clO: IF A.3/2 THEN m ELSE IF A.4/38 THEN o ELSE n/a - - P-CSCF, the Reason header field for the session 

initiation protocol. 
c1 1 : IF A. 4/40 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 



Prerequisite A.5/4 - - CANCEL request 

Table A.24: Supported message bodies within the CANCEL request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A.5/5 - - CANCEL response for all status-codes 



Table A.25: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


5 


From 


[261 20.20 


m 


m 


[26] 20.20 


m 


m 


5A 


Privacy 


[33] 4.2 


c3 


n/a 


[33] 4.2 


c3 


n/a 


6 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


7 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7A 


User-Agent 


[26] 20.41 








[26] 20.41 








8 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


9 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 



Prerequisite A.5/5 - - CANCEL response 
Prerequisite: A. 6/102 - - Additional for 2xx response 

Table A.26: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


4 


Supported 


[26] 20.37 





m 


[26] 20.37 


m 


m 



Prerequisite A.5/5 - - CANCEL response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.26A: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Table A.27: Void 



Prerequisite A.5/5 - - CANCEL response 



Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for Entity Too 
Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 
(Busy Everywhere), 603 (Decline) response 

Table A.28: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.30: Void 

Prerequisite A.5/5 - - CANCEL response 

Table A.31 : Supported message bodies within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.5 

Void 



COMET method 



A.2.1.4.6 INFO method 

Void 

A.2.1.4.7 INVITE method 

Prerequisite A.5/8 - - INVITE request 



Table A.46: Supported headers within the INVITE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Contact 


[56B] 9.2 


c24 


c24 


[56B] 9.2 


c32 


c32 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


4 


Alert- Info 


[26] 20.4 








[26] 20.4 


Cl 


cl 


5 


Allow 


[26] 20.5, 
[26] 5.1 


(note 1 ) 





[26] 20.5, 
[26] 5.1 


m 


m 


6 


Allow-Events 


[28] 7.2.2 


c2 


c2 


[28] 7.2.2 


c2 


c2 


8 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


9 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


10 


Call-Info 


[26] 20.9 








[26] 20.9 








11 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


12 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


13 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


14 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


15 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


16 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


17 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


18 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


19 


Expires 


[26] 20.19 








[26] 20.19 








20 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


20A 


History-Info 


[66] 4.1 


c31 


c31 


[66] 4.1 


c31 


c31 


21 


In-Reply-To 


[26] 20.21 








[26] 20.21 








21A 


Join 


[61] 7.1 


c30 


c30 


[61] 7.1 


c30 


c30 


22 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


23 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


23A 


Min-SE 


[58] 5 


c26 


c26 


[58] 5 


c25 


c25 


24 


Organization 


[26] 20.25 








[26] 20.25 








24A 


P-Access- N etwo rk- 1 nf o 


[52] 4.4 


c15 


c16 


[52] 4.4 


c15 


c17 


24B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c7 


c7 


24C 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


c13 


c13 


24D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c21 


[52] 4.5 


c20 


c21 


24E 


P-Charging-Vector 


[52] 4.6 


c18 


c19 


[52] 4.6 


c18 


c19 


25 


P-Media-Authorization 


[31] 5.1 


n/a 


n/a 


[31] 5.1 


c11 


c12 


25A 


P-Preferred-ldentity 


[34] 9.2 


c7 


c5 


[34] 9.2 


n/a 


n/a 


25B 


P-Profile-Key 


[97] 5 


n/a 


n/a 


[97] 5 


n/a 


n/a 


25C 


P-User-Database 


[82] 4 


n/a 


n/a 


[82] 4 


n/a 


n/a 


25D 


P-Visited-Network-ID 


[52] 4.3 


X (note 3) 


X 


[52] 4.3 


c14 


n/a 


26 


Priority 


[26] 20.26 








[26] 20.26 








26A 


Privacy 


[33] 4.2 


c9 


c9 


[33] 4.2 


c9 


c9 


27 


Proxy-Authorization 


[26] 20.28 


c6 


c6 


[26] 20.28 


n/a 


n/a 


28 


Proxy-Require 


[26] 20.29 


(note 2) 


(note 2) 


[26] 20.29 


n/a 


n/a 


28A 


Reason 


[34A] 2 


c8 


c8 


[34A] 2 


c8 


c8 


29 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


m 


m 


30 


Referred-By 


[59] 3 


c27 


c27 


[59] 3 


c28 


c28 


31 


Reject-Contact 


[56B] 9.2 


c24 


c24 


[56B] 9.2 


c32 


c32 
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Item 


Header 


Sending 


Receiving 




Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


31A 


Replaces 


[60] 6.1 


c29 


c29 


[60] 6.1 


c29 


c29 


31B 


Reply-To 


[26] 20.31 








[26] 20.31 








31B 


Request-Disposition 


[56B] 9.1 


c24 


c24 


[56B] 9.1 


c32 


c32 


32 


Require 


[26] 20.32 





m 


[26] 20.32 


m 


m 


33 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


33A 


Security-Client 


[48] 2.3.1 


c22 


c22 


[48] 2.3.1 


n/a 


n/a 


33B 


Security-Verify 


[48] 2.3.1 


c23 


c23 


[48] 2.3.1 


n/a 


n/a 


33C 


Session-Expires 


[58] 4 


c25 


c25 


[58] 4 


c25 


c25 


34 


Subject 


[26] 20.36 








[26] 20.36 








35 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


36 


Timestamp 


[26] 20.38 


clO 


c10 


[26] 20.38 


m 


m 


37 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


38 


User-Agent 


[26] 20.41 








[26] 20.41 








39 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


Cl: 
c2: 
c3: 
c4: 
c5: 

c6: 
c7: 

c8: 
c9: 
c10 
c11 
c12 
c13 
c14 
c15 
c16 
c17 

c18 
c19 
c20 
c21 
c22 
c23 
c24 
c25 
c26 
c27 
c28 
c29 
c30 
c31 

c32 
0.1: 


IF A. 4/1 2 THEN m ELSE n/a - - downloading of alerting information. 

IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A. 4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A. 4/1 9 THEN m ELSE n/a - - SIP extensions for media authorization. 

IF A.3/1 THEN m ELSE n/a - - UE. 

IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 

IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 

IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.4/37 THEN o ELSE n/a - - security mechanism agreement for the session initiation protocol (note 4). 

IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

IF A. 4/40 THEN o ELSE n/a - - caller preferences for the session initiation protocol. 

IF A.4/42 THEN m ELSE n/a - - the SIP session timer. 

IF A.4/42 THEN o ELSE n/a - - the SIP session timer. 

IF A.4/43 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

IF A.4/43 THEN o ELSE n/a - - the SIP Referred-By mechanism. 

IF A.4/44 THEN m ELSE n/a - - the Session Inititation Protocol (SIP) "Replaces" header. 

IF A.4/45 THEN m ELSE n/a - - the Session Inititation Protocol (SIP) "Join" header. 

IF A.4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 

IF A. 4/40 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

At least one of these shall be supported. 


NOTE 1 : RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 

NOTE 2: No distinction has been made in these tables between first use of a request on a From/To/Call-ID 

combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included 

from a viewpoint of first usage. 
NOTE 3: The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than IVIUST NOT. 
NOTE 4: Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 

defined by 3GPP TS 33.203 [19]. 
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Prerequisite A.5/8 - - INVITE request 

Table A.47: Supported message bodies within the INVITE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.48: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - 


- insertion of date in requests and responses. 
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Prerequisite A.5/9 - - INVITE response for all remaining status-codes 



Table A.49: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c12 


c12 


[26] 20.5 


m 


m 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Call-Info 


[26] 20.9 








[26] 20.9 








2 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26120.17 


c1 


Cl 


[26] 20.17 


m 


m 


8'- 


Expires 


[26] 20.19 








[26] 20.19 








9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c13 


c13 


[66] 4.1 


c13 


c13 


10 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


11 


Organization 


[26] 20.25 








[26] 20.25 








11A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


11B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


lie 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


c11 


c11 


11D 


P-Charging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


11E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


11F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


11G 


Reply-To 


[26] 20.31 








[26] 20.31 








11H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


111 


Server 


[26] 20.35 








[26] 20.35 








12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
g4: if A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO; IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c12: IF A.6/6 OR A.6/18 THEN m ELSE o - - 200 (OK), 405 (Method Not Allowed). 
c13; IF A.4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 
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Prerequisite A.5/9 - - INVITE response 
Prerequisite: A. 6/101 - - Additional for Ixx response 



Table A.50: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Contact 


[26] 20.10 





m 


[26] 20.10 


m 


m 


6 


P-Media-Authorization 


[31] 5.1 


n/a 


n/a 


[31] 5.1 


c11 


c12 


9 


Rseq 


[27] 7.1 


c2 


m 


[27] 7.1 


c3 


m 


c2; IF A. 4/1 4 THEN o ELSE n/a - - reliability of provisional responses in SIP. 
c3: IF A.4/14 THEN m ELSE n/a - - reliability of provisional responses in SIP. 
c11: IF A. 4/1 9 THEN m ELSE n/a - - SIP extensions for media authorization. 
c12: IF A.3/1 THEN m ELSE n/a-- UE. 



Prerequisite A.5/9 - - INVITE response 
Prerequisite: A. 6/102 - - Additional for 2xx response 



Table A.51 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


1B 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


c3 


c3 


[28] 7.2.2 


c4 


c4 


4 


Authentication-Info 


[26] 20.6 


Cl 


c1 


[26] 20.6 


c2 


c2 


6 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


8 


P-Media-Authorization 


[31] 5.1 


n/a 


n/a 


[31] 5.1 


c11 


c12 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


m 


m 


10 


Session-Expires 


[58] 4 


c13 


c13 


[58] 4 


c13 


c13 


13 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
c3: IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
c4: IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
c11: IF A.4/19THEN m ELSE n/a- - SIP extensions for media authorization. 
c12: IF A.3/1 THEN m ELSE n/a-- UE. 
c13: IF A.4/42 THEN m ELSE n/a - - the SIP session timer. 
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Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.51 A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/103 OR A. 6/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.52: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Contact 


[26)20.10 


(note 1) 





[26] 20.10 


m 


m 


NOTE: 


The strength of this requirement is RECOMMENDED rather than OPTIONAL. 







Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/14 - - Additional for 401 (Unauthorized) response 



Table A.53: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Proxy-Authenticate 


[26] 20.27 


c3 


c3 


[26] 20.27 


c3 


c3 


13 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/50 OR A.6/51 - - Additional for 404 (Not Found), 413 
(Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal Server Error), 600 (Busy 
Everywhere), 603 (Decline) response 

Table A.54: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


8 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.55: Void 

Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.56: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


6 


Proxy-Autlienticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


11 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.57: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.58: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


10 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.58A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 
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Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/28A - - Additional for 422 (Session Interval Too Small) response 

Table A.58B: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Min-SE 


[58] 5 


c1 


c1 


[58] 5 


c1 


c1 


c1: 


IF A.4/42 THEN o ELSE n/a - - the SIP session timer. 











Table A.59: Void 

Table A.60: Void 

Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/45 - - 503 (Service Unavailable) 

Table A.61 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Retry-After 


[26] 20.33 








[26] 20.33 





m 



Prerequisite A.5/9 - - INVITE response 

Table A.62: Supported message bodies within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.7A MESSAGE method 

Prerequisite A.5/9A - - MESSAGE request 



Table A.62A: Supported headers within the MESSAGE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept-Contact 


[56B] 9.2 


c24 


c24 


[56B] 9.2 


c28 


c28 


1A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


c1 


c1 


[28] 7.2.2 


c2 


c2 


3 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Call-Info 


[26] 20.9 








[26] 20.9 








6 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


7 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


8 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


9 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


10 


Content-Type 


[26] 20.15 


m 


m 


[26] 29.15 


m 


m 


11 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


12 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


13 


Expires 


[26] 20.19 








[26] 20.19 








14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


14A 


History-Info 


[66] 4.1 


c27 


c27 


[66] 4.1 


c27 


c27 


15 


In-Reply-To 


[26] 20.21 








[26] 20.21 








16 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


17 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


18 


Organization 


[26] 20.25 








[26] 20.25 








18A 


P-Access-Network-lnfo 


[52] 4.4 


c15 


c16 


[52] 4.4 


c15 


c16 


18B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c11 


c11 


18C 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


c13 


c13 


18D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c21 


[52] 4.5 


c20 


c21 


18E 


P-Charging-Vector 


[52] 4.6 


c18 


c19 


[52] 4.6 


c18 


c19 


18F 


P-Preferred-ldentity 


[34] 9.2 


c11 


c7 


[34] 9.2 


n/a 


n/a 


18G 


P-Profile-Key 


[97] 5 


n/a 


n/a 


[97] 5 


n/a 


n/a 


18H 


P-User-Database 


[82] 4 


n/a 


n/a 


[82] 4 


n/a 


n/a 


181 


P-Visited-Network-ID 


[52] 4.3 


X (note 1) 


X 


[52] 4.3 


c14 


n/a 


19 


Priority 


[26] 20.26 








[26] 20.26 








19A 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c12 


c12 


20 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


21 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


21A 


Reason 


[34A] 2 


c6 


c6 


[34A] 2 


c6 


c6 


22 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


22A 


Referred-By 


[59] 3 


c25 


c25 


[59] 3 


c26 


c26 


23 


Reject-Contact 


[56B] 9.2 


c24 


c24 


[56B] 9.2 


c28 


c28 


23A 


Reply-To 


[26] 20.31 








[26] 20.31 








23B 


Request-Disposition 


[56B] 9.1 


c24 


c24 


[56B] 9.1 


c28 


c28 


24 


Require 


[26] 20.32 


c8 





[26] 20.32 


m 


m 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


25A 


Security-Client 


[48] 2.3.1 


c22 


c22 


[48] 2.3.1 


n/a 


n/a 


25B 


Security-Verify 


[4812.3.1 


c23 


c23 


[48] 2.3.1 


n/a 


n/a 


26 


Subject 


[26] 20.35 








[26] 20.36 








27 


Supported 


[26] 20.37 


c9 


m 


[26] 20.37 


m 


m 


28 


Timestamp 


[26] 20.38 


c10 


c10 


[26] 20.38 


m 


m 


29 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


30 


User-Agent 


[26] 20.41 








[26] 20.41 








31 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



c1: 
c2: 
c3: 
c4: 
c5: 
c6: 
c7: 

c8: 
c9: 
c10: 
c11: 

c12 
c13 
c14 
c15 
c16 
c17 

c18 
c19 
c20 
c21 
c22 
c23 
c24 
c25 
c26 
c27 

c28: 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A. 4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/14 THEN o.1 ELSE o - - Reliable transport. 

IF IF A.4/14 THEN o.l ELSE o - - support of reliable transport. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 

IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 2). 

- security mechanism agreement for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 
- an extension to the session initiation protocol for request history 



IF A.4/36 THEN m ELSE n/a 
IF A.4/35 THEN ELSE n/a 
IFA.4/35THENm ELSE n/a 
IF A.4/37 THEN ELSE n/a 
IFA.4/37THENm ELSE n/a 
IF A.4/40 THEN ELSE n/a 
IF A.4/43 THEN m ELSE n/a 
IF A.4/43 THEN ELSE n/a 
IFA.4/47THENm ELSE n/a 
information. 
IF A.4/40 THEN m ELSE n/a 



- caller preferences for the session initiation protocol. 



NOTE 1 : The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 

NOTE 2: Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/9A - - MESSAGE request 

Table A.62B: Supported message bodies within the MESSAGE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.62BA: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


c1 


[26)20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IFA.4/11 THEN ELSE n/a -- i 


nsertion of date in requests and responses. 
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Prerequisite A.5/9B - - MESSAGE response for all status-codes 



Table A.62C: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c12 


c12 


[26] 20.5 


m 


m 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Call-Info 


[26] 20.9 








[26] 20.9 








3 


Content-Disposition 


[26] 20.11 


(note 2) 


(note 2) 


[26] 20.11 


m 
(note 2) 


m 
(note 2) 


4 


Content-Encoding 


[26] 20.12 


(note 2) 


(note 2) 


[26] 20.12 


m 
(note 2) 


m 
(note 2) 


5 


Content-Language 


[26] 20.13 


(note 2) 


(note 2) 


[26] 20.13 


m 
(note 2) 


m 
(note 2) 


6 


Content-Length 


[26] 20.14 


m 
(note 2) 


m 
(note 2) 


[26] 20.14 


m 
(note 2) 


m 
(note 2) 


7 


Content-Type 


[26] 20.15 


m 
(note 2) 


m 
(note 2) 


[26] 20.15 


m 
(note 2) 


m 
(note 2) 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26] 20.17 


c1 


Cl 


[26] 20.17 


m 


m 


9A 


Expires 


[26] 20.19 








[26] 20.19 








10 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10A 


History-Info 


[66] 4.1 


c13 


c13 


[66] 4.1 


c13 


c13 


11 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


12 


Organization 


[26] 20.25 








[26] 20.25 








12A 


P-Access- N etwo rk- 1 nf o 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


12B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


12C 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


c10 


c11 


12D 


P-Charging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


12E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


12F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


12G 


Reply-To 


[26] 20.31 








[26] 20.31 








12H 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


13 


Server 


[26] 20.35 








[26] 20.35 








14 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


15 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


16 


User-Agent 


[26] 20.41 








[26] 20.41 








17 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


18 


Warning 


[26] 20.43 








[26] 20.43 








c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
g4: if A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c12: IF A.6/18 THEN m ELSE o - - 405 (Method Not Allowed). 
c13: IF A. 4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 


NOTE 1 : RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 

NOTE 2: RFC 3428 [50] clause 7 states that all 2xx class responses to a MESSAGE request must not include any 
body, therefore for 2xx responses to the MESSAGE request the values on Sending side for "RFC status" 
and "Profile status" are "x", the values for Receiving side for "RFC status" and "Profile Status" are "n/a". 
RFC 3261 [26] subclause 7.4 states that all responses may contain bodies, therefore for all responses to 
the MESSAGE request other than 2xx responses, the values on Sending side for "RFC status" and "Profile 
status" are "o", the values for Receiving side for "RFC status" and "Profile Status" are "m". 
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Table A.62D: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


c3 


c3 


[28] 7.2.2 


c4 


c4 


2 


Authentication-Info 


[26] 20.6 


c1 


Cl 


[26] 20.6 


c2 


c2 


4 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
c3: IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
c4: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 



Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.62DA: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/103 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.62E: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


NOTE: 


The strength of this requirement is RECOMMENDED rather than OPTIONAL. 







Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/14 - - Additional for 401 (Unauthorized) response 

Table A.62F: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


cl 


cl 


[26] 20.27 


cl 


c1 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


cl : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 
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Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.62G: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Retry-After 


[26] 20.33 








[26] 20.33 









Table A.62H: Void 

Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.62I: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Autlientlcate 


[26] 20.27 


c1 


c1 


[26] 20.27 


c1 


c1 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.62J: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.62K: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 
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Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.62L: Supported headers within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


c1 


c1 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 



Table A.62l\/!: Void 

Prerequisite A.5/9B - - MESSAGE response 

Table A.62N: Supported message bodies within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.8 NOTIFY method 

Prerequisite A.5/10 - - NOTIFY request 



Table A.63: Supported headers within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Contact 


[56B] 9.2 


c19 


c19 


[56B] 9.2 


c23 


c23 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15A 


History-Info 


[66] 4.1 


c22 


c22 


[66] 4.1 


c22 


c22 


16 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


17 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


17A 


P-Access-Network-lnfo 


[52] 4.4 


c10 


c11 


[52] 4.4 


clO 


c12 


17B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c6 


c6 


17C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c15 


[52] 4.5 


c14 


c15 


17D 


P-Charging-Vector 


[52] 4.6 


c13 


n/a 


[52] 4.6 


c13 


n/a 


17E 


P-Preferred-ldentity 


[34] 9.2 


c6 


X 


[34] 9.2 


n/a 


n/a 


17F 


Privacy 


[33] 4.2 


c7 


n/a 


[33] 4.2 


c7 


c7 


18 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


19 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


19A 


Reason 


[34A] 2 


c18 


c18 


[34A] 2 


c18 


c18 


20 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


c9 


c9 


20A 


Referred-By 


[59] 3 


c20 


c20 


[59] 3 


c21 


c21 


20B 


Reject-Contact 


[56B] 9.2 


c19 


c19 


[56B] 9.2 


c23 


c23 


20C 


Request-Disposition 


[56B] 9.1 


c19 


c19 


[56B] 9.1 


c23 


c23 


21 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


22A 


Security-Client 


[48] 2.3.1 


c16 


c16 


[48] 2.3.1 


n/a 


n/a 


22B 


Security-Verify 


[48] 2.3.1 


c17 


c17 


[48] 2.3.1 


n/a 


n/a 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


23 


Subscription-State 


[28] 8.2.3 


m 


m 


[28] 8.2.3 


m 


m 


24 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


25 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 








[26] 20.41 








28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


29 


Warning 


[26] 20.43 








[26] 20.43 
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c1: 
c2: 
c3: 
c4: 
c5: 
c6: 

c7: 
c8: 
c9: 

c10 
c11 
c12 

c13 
c14 
c15 
c16 
c17 
c18 
c19 
c20 
c21 
c22 

c23: 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.4/15 OR A.4/20 THEN m ELSE n/a - - the REFER method extension or SIP specific event notification 

extension. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note). 

- security mechanism agreement for the session initiation protocol. 

- the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 
- an extension to the session initiation protocol for request history 



IFA.4/35THENm ELSE n/a ■ 
IF A.4/37 THEN ELSE n/a - 
IFA.4/37THENm ELSE n/a • 
IF A.4/38 THEN ELSE n/a - 
IF A.4/40 THEN ELSE n/a - 
IF A.4/43 THEN m ELSE n/a ■ 
IF A.4/43 THEN ELSE n/a - 
IFA.4/47THENm ELSE n/a • 
information. 
IF A.4/40 THEN m ELSE n/a ■ 



■ caller preferences for the session initiation protocol. 



NOTE: Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/10 - - NOTIFY request 

Table A.64: Supported message bodies within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


sipfrag 


[37] 2 


Cl 


cl 


[37] 


cl 


cl 


c1: 


IF A.4/15 THEN m ELSE o - 


- the REFER method extension 









Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.64A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


cl 


c1 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


cl : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
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Prerequisite A.5/1 1 - - NOTIFY response for all status-codes 



Table A.65: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26)20.11 








[26)20.11 


m 


m 


3 


Content-Encoding 


[26)20.12 








[26)20.12 


m 


m 


4 


Content-Language 


[26)20.13 








[26)20.13 


m 


m 


5 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


m 


m 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


Cl 


cl 


[26)20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


10B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


IOC 


P-Charging-Function- 
Addresses 


[52) 4.5 


c9 


clO 


[52) 4.5 


c9 


ClO 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


n/a 


[52] 4.6 


c8 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10F 


Privacy 


[33] 4.2 


c4 


n/a 


[33] 4.2 


c4 


c4 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


10H 


Server 


[26] 20.35 








[26) 20.35 








11 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


c2 


c2 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


(26) 20.43 


(note) 





[26) 20.43 








c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
g4: if A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
clO: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.6/1 8 THEN m ELSE o - - 405 (Method Not Allowed) 


NOTE: RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 



Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A. 6/102 - - Additional for 2xx response 



Table A.66: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


c4 


c4 


[28) 7.2.2 


c5 


c5 


1 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


1A 


Contact 


[26)20.10 








[26)20.10 


m 


m 


2 


Record-Route 


[26) 20.30 


c3 


c3 


[26) 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 

c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

c3: IF A.4/15 OR A.4/20 THEN m ELSE n/a - - the REFER method extension or SIP specific event notification 

extension. 
c4: IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
c5: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.66A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A.6/103 - - Additional for 3xx response 

Table A.67: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A. 6/14 - - Additional for 401 (Unauthorized) response 



Table A.68: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 ; IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.69: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.70: Void 

Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.71 : Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Proxy-Autlienticate 


[26] 20.27 


c3 


c3 


[26] 20.27 


c3 


c3 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c3: IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.72: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/27 - - Addition for 420 (Bad Extension) response 

Table A.73: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.73A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


Cl 


cl 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 
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Table A.74: Void 

Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/35 - - Additional for 485 (Ambigious) response 

Table A.74A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Contact 


[26120.10 








[26] 20.10 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/39 - - Additional for 489 (Bad Event) response 

Table A.75: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 

Table A.76: Supported message bodies within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.9 OPTIONS method 

Prerequisite A.5/12 - - OPTIONS request 



Table A.77: Supported headers within the OPTIONS request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


m 


m 


1A 


Accept-Contact 


[56B] 9.2 


c21 


c21 


[56B] 9.2 


c26 


c26 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


c24 


c24 


[28] 7.2.2 


c1 


Cl 


5 


Authorization 


[26] 20.7 


c2 


c2 


[26] 20.7 


c2 


c2 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 








[26] 20.9 








8 


Contact 


[26)20.10 








[26] 20.10 








9 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


10 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


11 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26120.15 


m 


m 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


c3 


c3 


[26] 20.17 


m 


m 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16A 


History-Info 


[66] 4.1 


c25 


c25 


[66] 4.1 


c25 


c25 


17 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


18 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


19 


Organization 


[26] 20.25 








[26] 20.25 








19A 


P-Access-Network-lnfo 


[52] 4.4 


c11 


c12 


[52] 4.4 


c11 


c13 


19B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[341 9.1 


c6 


c6 


19C 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


c9 


c9 


19D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c16 


c17 


[52] 4.5 


c16 


c17 


19E 


P-Charging-Vector 


[52] 4.6 


c14 


c15 


[52] 4.6 


c14 


c15 


19F 


P-Preferred-ldentity 


[34] 9.2 


c6 


c4 


[34] 9.2 


n/a 


n/a 


19G 


P-Profile-Key 


[9715 


n/a 


n/a 


[9715 


n/a 


n/a 


19H 


P-User-Database 


[82] 4 


n/a 


n/a 


[8214 


n/a 


n/a 


191 


P-Visited-Network-ID 


[52] 4.3 


X (note 2) 


X 


[52] 4.3 


c10 


n/a 


19J 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c8 


c8 


20 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


21 


Proxy-Require 


[26] 20.29 





(note 1 ) 


[26] 20.29 


n/a 


n/a 


21A 


Reason 


[34A] 2 


c20 


c20 


[34A] 2 


c20 


c20 


22 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


22A 


Referred-By 


[59] 3 


c22 


c22 


[59] 3 


c23 


c23 


22B 


Reject-Contact 


[56B1 9.2 


c21 


c21 


[56B1 9.2 


c26 


c26 


22C 


Request-Disposition 


[56B] 9.1 


c21 


c21 


[56B] 9.1 


c26 


c26 


23 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


24A 


Security-Client 


[48] 2.3.1 


c18 


c18 


[48] 2.3.1 


n/a 


n/a 


24B 


Security-Verify 


[4812.3.1 


c19 


c19 


[481 2.3.1 


n/a 


n/a 


25 


Supported 


[26] 20.37 


c6 


c6 


[26] 20.37 


m 


m 


26 


Timestamp 


[26] 20.38 


c7 


c7 


[26] 20.38 


m 


m 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 








[26] 20.41 








29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3: 
c4: 

c5: 
c6: 

c7: 
c8: 
c9: 
c10 
c11 
c12 
c13 

c14 
c15 
c16 
c17 
c18 
c19 
c20 
c21 
c22 
c23 
c24 
c25 

c26: 



IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 

IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 3). 

- security mechanism agreement for the session initiation protocol. 

- the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 

- SIP specific event notification extension. 

- an extension to the session initiation protocol for request history 



IF A.4/36 THEN m ELSE n/a ■ 
IF A.4/35 THEN ELSE n/a - 
IFA.4/35THENm ELSE n/a ■ 
IF A.4/37 THEN ELSE n/a - 
IFA.4/37THENm ELSE n/a • 
IF A.4/38 THEN ELSE n/a - 
IF A.4/40 THEN ELSE n/a - 
IF A.4/43 THEN m ELSE n/a ■ 
IF A.4/43 THEN ELSE n/a - 
IF A.4/20 THEN ELSE n/a - 
IFA.4/47THENm ELSE n/a • 
information. 
IF A.4/40 THEN m ELSE n/a ■ 



- caller preferences for the session initiation protocol. 



NOTE 1 : 



NOTE 2: 
NOTE 3: 



No distinction has been made in these tables between first use of a request on a From/To/Call-ID 

combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included 

from a viewpoint of first usage. 

The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than IVIUST NOT. 

Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 

defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/12 - - OPTIONS request 

Table A.78: Supported message bodies within the OPTIONS request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Table A.79: Void 

Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 

Table A.79A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
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Prerequisite A.5/13 - - OPTIONS response for all status-codes 



Table A.80: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c12 


c12 


[26] 20.5 


m 


m 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Call-Info 


[26] 20.9 








[26] 20.9 








2 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26120.17 


Cl 


cl 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c13 


c13 


[66] 4.1 


c13 


c13 


10 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


11 


Organization 


[26] 20.25 








[26] 20.25 








11A 


P-Access- N etwo rk- 1 nf o 


[52] 4.4 


c5 


c6 


[521 4.4 


c5 


c7 


11B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


lie 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


ClO 


c11 


11D 


P-Charging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


11E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


11F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


11G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


11H 


Server 


[26] 20.35 








[26] 20.35 








12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
g4: if A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c12: IF A.6/6 OR A.6/18 THEN m ELSE o - - 200 (OK), 405 (Method Not Allowed). 
c13: IF A. 4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 


NOTE: RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 
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Table A.81 : Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


m 


m 


1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


m 


m 


IB 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


c3 


c3 


[28] 7.2.2 


c4 


c4 


3 


Authentication-Info 


[26] 20.6 


Cl 


cl 


[26] 20.6 


c2 


c2 


5 


Contact 


[26)20.10 







[26] 20.10 







8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
c3: IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
c4: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 



Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.81 A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/103 OR A. 6/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.82: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


NOTE: RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 



Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A. 6/14 - - Additional for 401 (Unauthorized) response 



Table A.83: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


cl 


cl 


[26] 20.27 


cl 


cl 


10 


www-Authenticate 


[26] 20.44 







[26] 20.44 







cl : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 
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Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response. 

Table A.84: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Retry-After 


[26] 20.33 








[26] 20.33 









Table A.85: Void 

Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.86: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Autlientlcate 


[26] 20.27 


c1 


c1 


[26] 20.27 


c1 


c1 


8 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.87: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.88: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 
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Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/28 OR A.6/41A - - Additional 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.88A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


c1 


c1 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 



Table A.89: Void 

Prerequisite A.5/13 - - OPTIONS response 

Table A.90: Supported message bodies within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



202 



ETSI TS 124 229 V7.6.0 (2006-12) 



A.2.1.4.10 PRACK method 

Prerequisite A.5/14 - - PRACK request 



Table A.91 : Supported headers within the PRACK request 



Item 


Header 


Sending 


Receiving 




Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Contact 


[56B] 9.2 


c15 


c15 


[56B] 9.2 


c18 


c18 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


16 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c9 


c10 


[52] 4.4 


c9 


oil 


16B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c13 


c14 


[52] 4.5 


c13 


c14 


16C 


P-Charging-Vector 


[52] 4.6 


c12 


n/a 


[52] 4.6 


c12 


n/a 


16D 


Privacy 


[33] 4.2 


c6 


n/a 


[33] 4.2 


c6 


n/a 


17 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


18 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


19 


Rack 


[27] 7.2 


m 


m 


[27] 7.2 


m 


m 


19A 


Reason 


[34A] 2 


c7 


c7 


[34A] 2 


c7 


c7 


20 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


20A 


Referred-By 


[59] 3 


c16 


c16 


[59] 3 


c17 


c17 


20B 


Reject-Contact 


[56B] 9.2 


c15 


c15 


[56B] 9.2 


c18 


c18 


20C 


Request-Disposition 


[56B] 9.1 


c15 


c15 


[56B] 9.1 


c18 


c18 


21 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


23 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


24 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


25 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


26 


User-Agent 


[26] 20.41 








[26] 20.41 








27 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 
c2: 
c3: 
c4: 
c5: 
c6: 
c7: 
c8: 
c9: 
clO 
c11 

c12 
c13 
c14 
c15 
c16 
c17 
c18 


IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A. 4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A. 4/40 THEN o ELSE n/a - - caller preferences for the session initiation protocol. 

IF A.4/43 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

IF A.4/43 THEN o ELSE n/a - - the SIP Referred-By mechanism. 

IF A. 4/40 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 
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Prerequisite A.5/14 - - PRACK request 

Table A.92: Supported message bodies within the PRACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Table A.93: Void 

Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.93A: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26120.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


c1 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IFA.4/11 THEN ELSE n/a -- i 


nsertion of date in requests and respor 


ises. 
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Prerequisite A.5/15 - - PRACK response for all status-codes 



Table A.94: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c9 


c9 


[26] 20.5 


m 


m 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26)20.11 








[26)20.11 


m 


m 


3 


Content-Encoding 


[26)20.12 








[26)20.12 


m 


m 


4 


Content-Language 


[26)20.13 








[26)20.13 


m 


m 


5 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


m 


m 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


Cl 


cl 


[26)20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c3 


c4 


[52] 4.4 


c3 


c5 


10B 


P-Charging-Function- 
Addresses 


[52) 4.5 


c7 


c8 


[52) 4.5 


c7 


c8 


10C 


P-Charging-Vector 


[52] 4.6 


c6 


n/a 


[52] 4.6 


c6 


n/a 


10D 


Privacy 


[33) 4.2 


c2 


n/a 


[33) 4.2 


c2 


n/a 


10E 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


10F 


Server 


[26] 20.35 








[26) 20.35 








11 


Timestamp 


[26) 20.38 


m 


m 


[26) 20.38 


c2 


c2 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26) 20.43 


(note) 





[26) 20.43 








c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c3: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

g4: if A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c5: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c6: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c7: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c8: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c9: IF A.6/18 THEN m ELSE o - - 405 (Method Not Allowed) 


NOTE: RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 



Prerequisite A.5/15 - - PRACK response 
Prerequisite: A. 6/102 - - Additional for 2xx response 



Table A.95: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


c3 


c3 


[28) 7.2.2 


c4 


c4 


OB 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


3 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
c3: IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
c4: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
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Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.95A: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/103 OR A. 6/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.96: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Contact 


[26)20.10 


(note) 





[26] 20.10 


m 


m 


NOTE: RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 



Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/14 - - Additional for 401 (Unauthorized) response 



Table A.97: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


cl 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response. 

Table A.98: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.99: Void 

Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.100: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Proxy-Autlienticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


c1 


c1 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.101 : Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 



Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A. 6/27 - - Additional for 420 (Bad Extension) response 

Table A.102: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A. 5/1 5 - - PRACK response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.102A: Supported headers within the PRACK response 



Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



Security-Server 



[48] 2 



[48] 2 



c1 



c1: IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 



c1 
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Table A.103: Void 

Prerequisite A. 5/1 5 - - PRACK response 

Table A.104: Supported message bodies within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.10A PUBLISH method 

Prerequisite A.5/15A - PUBLISH request 



Table A.104A: Supported headers within the PUBLISH request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept-Contact 


[568] 9.2 


c22 


c22 


[568] 9.2 


c28 


c28 


2 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Allow-Events 


[26] 7.2.2 


Cl 


cl 


[26] 7.2.2 


c2 


c2 


4 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


5 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6 


Call-Info 


[26] 20.9 








[26] 20.9 








7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


Event 


[70] 4, 6 


m 


m 


[70] 4, 6 


m 


m 


15 


Expires 


[26] 
20.19, 
[70] 4, 5, 
6 








[26] 
20.19, 
[70] 4, 5, 
6 


m 


m 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17 


In-Reply-To 


[26] 20.21 








[26] 20.21 








17A 


History-Info 


[66] 4.1 


c27 


c27 


[66] 4.1 


c27 


c27 


18 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


19 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


20 


Organization 


[26] 20.25 








[26] 20.25 








21 


P-Access-Network-lnfo 


[52] 4.4 


c15 


c16 


[52] 4.4 


c15 


c17 


22 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c11 


c11 


23 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


c13 


c13 


24 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c21 


[52] 4.5 


c20 


c21 


25 


P-Charging-Vector 


[52] 4.6 


c18 


c19 


[52] 4.6 


c18 


c19 


26 


P-Preferred-ldentity 


[34] 9.2 


c11 


c7 


[34] 9.2 


n/a 


n/a 


26A 


P-Profile-Key 


[97] 5 


n/a 


n/a 


[97] 5 


n/a 


n/a 


26B 


P-User-Database 


[82] 4 


n/a 


n/a 


[82] 4 


n/a 


n/a 


27 


P-Visited-Network-ID 


[52] 4.3 


X (note 3) 


X 


[52] 4.3 


c14 


n/a 


28 


Priorita 


[26] 20.26 








[26] 20.26 








29 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c12 


c12 


30 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


31 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


32 


Reason 


[34A] 2 


c8 


c8 


[34A] 2 


c8 


c8 


33 


Reject-Contact 


[56B] 9.2 


c22 


c22 


[56B] 9.2 


c28 


c28 


33A 


Referred-By 


[5913 


c25 


c25 


[5913 


c26 


c26 


34 


Request-Disposition 


[56B] 9.1 


c22 


c22 


[56B] 9.1 


c28 


c28 


35 


Reply-To 


[26] 20.31 








[26] 20.31 








36 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


37 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


38 


Security-Client 


[48] 2.3.1 


c9 


c9 


[48] 2.3.1 


n/a 


n/a 


39 


Security-Verify 


[48] 2.3.1 


c10 


clO 


[48] 2.3.1 


n/a 


n/a 


40 


SIP-lf-Match 


[70] 
11.3.2 








[70] 
11.3.2 


m 


m 


41 


Subject 


[26] 20.36 








[26] 20.36 








42 


Supported 


[26] 
20.37, 
[26] 7.1 








[26] 
20.37, 
[26] 7.1 


m 


m 


43 


Timestamp 


[26] 20.38 


c6 


c6 


[26] 20.38 


m 


m 


44 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


45 


User-Agent 


[26] 20.41 








[26] 20.41 








46 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3: 
c4: 
c5: 
c6: 
c7: 

c8; 
c9: 
clO: 
c11: 

c12 
c13 
c14 
c15 
c16 
c17 

c18 
c19 
c20 
c21 
c22 
c25 
c26 
c27 

c28: 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A. 4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 

IF A. 4/37 THEN o ELSE n/a - - security mechanism agreement for the session initiation protocol (note 1). 

IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 

IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Vector header extension. 

■ the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

■ caller preferences for the session initiation protocol. 

- the SIP Referred-By mechanism, 
the SIP Referred-By mechanism. 

- an extension to the session initiation protocol for request history 



IF A.4/36 THEN m ELSE n/a 
IF A.4/35 THEN ELSE n/a 
IFA.4/35THENm ELSE n/a 
IF A.4/40 THEN ELSE n/a 
IF A.4/43 THEN m ELSE n/a 
IF A.4/43 THEN ELSE n/a 
IFA.4/47THENm ELSE n/a 
information. 
IF A.4/40 THEN m ELSE n/a 



- caller preferences for the session initiation protocol. 



NOTE 1 : Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. 
NOTE 2: The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 



Prerequisite A.5/15A - - PUBLISH request 

Table A.104B: Supported message bodies within the PUBLISH request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.104BA: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26120.14 


m 


m 


[26120.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


c1 


[26)20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
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Prerequisite A.5/15B - - PUBLISH response for all status-codes 



Table A.104C: Supported headers within the PUBLISIH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c12 


c12 


[26] 20.5 


m 


m 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Call-Info 


[26] 24.9 








[26] 24.9 


m 


m 


3 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


4 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


5 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


6 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26120.17 


Cl 


cl 


[26] 20.17 


m 


m 


10 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10A 


History-Info 


[66] 4.1 


c13 


c13 


[66] 4.1 


c13 


c13 


11 


IVIIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


12 


Organization 


[26] 20.25 








[26] 20.25 








13 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


14 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


15 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


c10 


c11 


16 


P-Charging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


17 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


18 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


19 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


20 


Server 


[26] 20.35 








[26] 20.35 








21 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


22 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


23 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


24 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


25 


Warning 


[26] 20.43 








[26] 20.43 








c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
g4: if A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c12: IF A.6/18 THEN m ELSE o - - 405 (Method Not Allowed). 
c13: IF A. 4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 
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Table A.104D: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Authentication-Info 


[26] 20.6 


Cl 


cl 


[26] 20.6 


c2 


c2 


3 


Expires 


[26] 
20.19, 
[70] 4, 5, 
6 


m 


m 


[26] 
20.19, 
[70] 4, 5, 
6 


m 


m 


4 


SIP-Etag 


[70] 
11.3.1 


m 


m 


[70] 
11.3.1 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 



Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.104DA: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26120.18 









Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/103 OR A. 6/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.104E: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Contact 


[26] 20.10 








[26] 20.10 


m 


m 



Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/1 lOR A.6/12 - Additional for 401 (Unauthorized) response 

Table A.104F: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


cl 


cl 


[26] 20.27 


cl 


cl 


5 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 
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Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.104G: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 








[26] 20.33 









Table A.104H: Void 

Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.104I: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Autlientlcate 


[26] 20.27 


c1 


c1 


[26] 20.27 


c1 


c1 


5 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.104J: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.104K: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 
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Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.104L: Supported headers within the PUBLISIH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


c1 


c1 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 



Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/29 - - Additional for 423 (Interval Too Brief) response 

Table A.104l\/I: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


IVIin-Expires 


[26] 
20.23, 
[70] 5, 6 


m 


m 


[26] 
20.23, 
[70] 5, 6 


m 


m 



Table A.104N: Void 

Prerequisite A.5/15B - - PUBLISH response 

Prerequisite: A.6/39 - - Additional for 489 (Bad Event) response 

Table A.104O: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Allow-Events 


[28] 8.2.2 


m 


m 


[28] 8.2.2 


m 


m 



Prerequisite A.5/15B - - PUBLISH response 

Table A.104P: Supported message bodies within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.11 REFER method 

Prerequisite A.5/16 - - REFER request 



Table A.105: Supported headers within the REFER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


OB 


Accept-Contact 


[56B] 9.2 


c22 


c22 


[56B] 9.2 


c25 


c25 


OC 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


1 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


1A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


3 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


5A 


Content-Disposition 


[26] 20.11 








[26120.11 


m 


m 


5B 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


5C 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


6 


Content-Length 


[26] 20.14 


m 


m 


[26120.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


8 


Cseq 


[26] 20.16 


m 


m 


[26120.16 


m 


m 


9 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


10 


Expires 


[26] 20.19 








[26] 20.19 








11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


11A 


History-Info 


[66] 4.1 


c24 


c24 


[66] 4.1 


c24 


c24 


12 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


13 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


14 


Organization 


[26] 20.25 








[26] 20.25 








14A 


P-Access-Network-lnfo 


[52] 4.4 


c12 


c13 


[52] 4.4 


c12 


c14 


14B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[341 9.1 


c8 


c8 


14C 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


clO 


clO 


14D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c17 


c18 


[52] 4.5 


c17 


c18 


14E 


P-Charging-Vector 


[52] 4.6 


c15 


c16 


[52] 4.6 


c15 


c16 


14F 


P-Preferred-ldentity 


[34] 9.2 


c8 


c7 


[34] 9.2 


n/a 


n/a 


14G 


P-Profile-Key 


[9715 


n/a 


n/a 


[9715 


n/a 


n/a 


14H 


P-User-Database 


[82] 4 


n/a 


n/a 


[8214 


n/a 


n/a 


141 


P-Visited-Network-ID 


[52] 4.3 


X (note 1 ) 


X 


[52] 4.3 


c11 


n/a 


14J 


Privacy 


[33] 4.2 


c9 


c9 


[33] 4.2 


c9 


c9 


15 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


16 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


16A 


Reason 


[34A] 2 


c21 


c21 


[34A] 2 


c21 


c21 


17 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


m 


m 


18 


Refer-To 


[36] 3 


m 


m 


[36] 3 


m 


m 


18A 


Referred-By 


[5913 


c23 


c23 


[5913 


c23 


c23 


18B 


Reject-Contact 


[56B] 9.2 


c22 


c22 


[56B1 9.2 


c25 


c25 


18C 


Request-Disposition 


[56B] 9.1 


c22 


c22 


[56B] 9.1 


c25 


c25 


19 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


20 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


20A 


Security-Client 


[481 2.3.1 


c19 


c19 


[481 2.3.1 


n/a 


n/a 


20B 


Security-Verify 


[4812.3.1 


c20 


c20 


[48] 2.3.1 


n/a 


n/a 


21 


Supported 


[26] 
20.37, 
[26] 7.1 








[26] 
20.37, 
[26] 7.1 


m 


m 


22 


Timestamp 


[26] 20.38 


c6 


c6 


[26] 20.38 


m 


m 


23 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


24 


User-Agent 


[261 20.41 








[26] 20.41 








25 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3: 
c4: 
c5: 
c6: 
c7: 

c8: 

c9: 
c10 
c11 
c12 
c13 
c14 

c15 
c16 
c17 
c18 
c19 
c20 
c21 
c22 
c23 
c24 

c25: 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 

IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 2). 

- security mechanism agreement for the session initiation protocol. 

- the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP Referred-By Mechanism. 

- an extension to the session initiation protocol for request history 



IF A.4/35 THEN ELSE n/a 
IFA.4/35THENm ELSE n/a 
IF A.4/37 THEN ELSE n/a 
IFA.4/37THENm ELSE n/a 
IF A.4/38 THEN ELSE n/a 
IF A.4/40 THEN ELSE n/a 
IF A.4/43 THEN m ELSE n/a 
IFA.4/47THENm ELSE n/a 
information. 
IF A.4/40 THEN m ELSE n/a 



■ caller preferences for the session initiation protocol. 



NOTE 1 : The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than IVIUST NOT. 

NOTE 2: Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/16 - - REFER request 

Table A.106: Supported message bodies within the REFER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Table A.I 07: Void 

Prerequisite A.5/17 - - REFER response for all status-codes 

Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 

Table A.107A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


c1 


[26)20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IFA.4/11 THEN ELSE n/a -- i 


nsertion of date in requests and responses. 
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Table A.108: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 




Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c12 


c12 


[26] 20.5 


m 


m 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Contact 


[26] 20.10 


c13 


c13 


[26] 20.10 


m 


m 


1B 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


2 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


3 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


4 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


5 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


6 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


7 


Date 


[26120.17 


c1 


Cl 


[26] 20.17 


m 


m 


8 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


8A 


History-Info 


[66] 4.1 


c14 


c14 


[66] 4.1 


c14 


c14 


9 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10 


Organization 


[26] 20.25 








[26] 20.25 








10A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


10B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


10C 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


c10 


c11 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


10E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


10H 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1: 
c2: 
c3: 

c4: 
c5: 
c6: 
c7: 

c8: 
c9: 
clO 
c11 
c12 
c13 
c14 


IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.6/18 THEN m ELSE o - - 405 (Method Not Allowed) 

IF A.6/102 THEN m ELSE o - - 2xx response. 

IF A.4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 



Prerequisite A.5/17 - - REFER response 
Prerequisite: A.6/102 - - Additional for 2xx response 



Table A.109: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


c3 


c3 


[28] 7.2.2 


c4 


c4 


2 


Authentication-Info 


[26] 20.6 


c1 


cl 


[26] 20.6 


c2 


c2 


5 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


m 


m 
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Supported 



[26] 20.37 I m 



m 



[26] 20.37 I m 



m 



c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 

c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

c3: IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

c4: IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 



Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.109A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Table A.1 10: Void 

Prerequisite A.5/17 - - REFER response 

Prerequisite: A. 6/14 - - Additional for 401 (Unauthorized) response 



Table A.111 : Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


cl 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.1 12: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


6 


Retry-After 


[26] 20.33 








[26] 20.33 









Table A.1 13: Void 

Prerequisite A.5/17 - - REFER response 

Prerequisite: A. 6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.1 14: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


cl 


cl 


[26] 20.27 


cl 


cl 


8 


www-Authenticate 


[26] 20.44 








[26] 20.44 








cl : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 
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Prerequisite A.5/17 - - REFER response 

Prerequisite: A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.115: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/17 - - REFER response 

Prerequisite: A. 6/27 - - Additional for 420 (Bad Extension) response 

Table A.116: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.116A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


Cl 


cl 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 



Table A.1 17: Void 

Prerequisite A.5/17 - - REFER response 

Table A.1 18: Supported message bodies within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.12 REGISTER method 

Prerequisite A.5/18 - - REGISTER request 



Table A.119: Supported headers within the REGISTER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


c27 


c27 


[28] 7.2.2 


c1 


Cl 


5 


Authorization 


[26] 20.7, 
[49] 


c2 





[26] 20.7, 
[49] 


m 


c22 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 








[26] 20.9 








8 


Contact 


[26] 20.10 





m 


[26] 20.10 


m 


m 


9 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


10 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


11 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


c3 


c3 


[26] 20.17 


m 


m 


16 


Expires 


[26] 20.19 








[26] 20.19 


m 


m 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17A 


History-Info 


[66] 4.1 


c28 


c28 


[66] 4.1 


c28 


c28 


18 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


19 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


20 


Organization 


[26] 20.25 








[26] 20.25 








20A 


P-Access- N etwo rk- 1 nf o 


[52] 4.4 


c12 


c13 


[52] 4.4 


c12 


c14 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c17 


c18 


[52] 4.5 


c17 


c18 


20C 


P-Charging-Vector 


[52] 4.6 


c15 


c16 


[52] 4.6 


c15 


c16 


20D 


P-User-Database 


[82] 4 


n/a 


n/a 


[82] 4 


c30 


c30 


20E 


P-Visited-Network-ID 


[52] 4.3 


x (note 2) 


X 


[52] 4.3 


clO 


c11 


20FE 


Path 


[35] 4 


c4 


c5 


[35] 4 


m 


c6 


20GF 


Privacy 


[33] 4.2 


c9 


n/a 


[33] 4.2 


c9 


n/a 


21 


Proxy-Authorization 


[26] 20.28 


c8 


c8 


[26] 20.28 


n/a 


n/a 


22 


Proxy-Require 


[26] 20.29 





(note 1 ) 


[26] 20.29 


n/a 


n/a 


22A 


Reason 


[34A] 2 


c23 


c23 


[34A] 2 


c23 


c23 


22B 


Referred-By 


[59] 3 


c25 


c25 


[59] 3 


c26 


c26 


22C 


Request-Disposition 


[56B] 9.1 


c24 


c24 


[56B] 9.1 


n/a 


n/a 


23 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


24 


Route 


[26] 20.34 





n/a 


[26] 20.34 


n/a 


n/a 


24A 


Security-Client 


[48] 2.3.1 


c19 


c20 


[48] 2.3.1 


n/a 


n/a 


24B 


Security-Verify 


[48] 2.3.1 


c20 


c20 


[48] 2.3.1 


c21 


n/a 


25 


Supported 


[26] 20.37 





c29 


[26] 20.37 


m 


m 


26 


Timestamp 


[26] 20.38 


c7 


c7 


[26] 20.38 


c7 


c7 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 








[26] 20.41 








29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



220 



ETSI TS 124 229 V7.6.0 (2006-12) 



c1: 
c2: 
c3: 
c4: 

c5: 

c6: 
c7: 
c8: 
c9: 
clO 
c11 
c12 
c13 

c14: 

c15: 
c16: 

c17: 
c18: 

c19 
c20 
c21 

c22 
c23 
c24 
c25 
c26 
c27 
c28 

c29: 
c30: 



IFA.4/20THENm ELSE n/a 

IFA.4/8THENm ELSE n/a - 

IFA.4/11 THEN ELSE n/a 

IF A.4/24 THEN ELSE n/a 

contacts. 

IF A.4/24 THEN X ELSE n/a- 

contacts. 

IF A.3/4 THEN m ELSE n/a. 

IFA.4/6THENm ELSE n/a - 



- - SIP specific event notification extension. 

- authentication between UA and registrar. 

- insertion of date in requests and responses. 

- session initiation protocol extension header field for registering non-adjacent 

- session initiation protocol extension header field for registering non-adjacent 



S-CSCF. 

timestamping of requests. 
IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 
IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 
IF A.4/33 THEN m ELSE n/a - - the P-Visited-Network-ID extension. 
IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND (A.3/1 OR A.3/4) THEN o ELSE n/a - - the P-Access-Network-lnfo header extension and UE 
or S-CSCF. 

IF A.4/34 AND (A.3/4 OR A.3/7A) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
S-CSCF or AS acting as terminating UA. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Vector header extension (including S-CSCF as 
registrar). 

IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
IF A. 4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including 
S-CSCF as registrar). 

IF A. 4/37 THEN o ELSE n/a - - security mechanism agreement for the session initiation protocol (note 3). 
IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
IF A.4/37 AND A. 4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 
and registrar. 

S-CSCF. 

- the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 

- SIP specific event notification extension. 

- an extension to the session Initiation protocol for request history 



IF A.3/4 THEN m ELSE n/a - 

IF A.4/38 THEN ELSE n/a - 

IF A.4/40 THEN ELSE n/a - 

IF A.4/43 THEN m ELSE n/a ■ 

IF A.4/43 THEN ELSE n/a - 

IF A.4/20 THEN ELSE n/a - 

IFA.4/47THENm ELSE n/a • 

information. 

IF A.3/1 THEN m ELSE o - - UE. 

IF A. 4/48 THEN m ELSE n/a - - the P-User-Database private header extension 



NOTE 1 : 



NOTE 2: 
NOTE 3: 



No distinction has been made in these tables between first use of a request on a From/To/Call-ID 

combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included 

from a viewpoint of first usage. 

The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than IVIUST NOT. 

Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. 



Prerequisite A.5/18 - - REGISTER request 

Table A.120: Supported message bodies within the REGISTER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Table A.121: Void 

Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 

Table A.121 A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
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Prerequisite A.5/19 - - REGISTER response for all status-codes 



Table A.122: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c8 


c8 


[26] 20.5 


m 


m 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Call-Info 


[26] 20.9 








[26] 20.9 








2 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26120.17 


c1 


Cl 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c9 


c9 


[66] 4.1 


c9 


c9 


10 


IVIIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


11 


Organization 


[26] 20.25 








[26] 20.25 








11A 


P-Access-Network-lnfo 


[52] 4.4 


c3 


n/a 


[52] 4.4 


c3 


n/a 


11B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c6 


c7 


[52] 4.5 


c6 


c7 


lie 


P-Charging-Vector 


[52] 4.6 


c4 


c5 


[52] 4.6 


c4 


c5 


11D 


Privacy 


[33] 4.2 


c2 


n/a 


[33] 4.2 


c2 


n/a 


11E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


11F 


Server 


[26] 20.35 








[26] 20.35 








12 


Timestamp 


[26] 20.38 


c2 


c2 


[26] 20.38 


m 


m 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c3: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c4: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c5: IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Vector header extension (including S-CSCF as 

registrar). 
c6: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c7: IF A.4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including 

S-CSCF as registrar). 
c8: IF A.6/18 THEN m ELSE o - - 405 (Method Not Allowed). 
c9: IF A.4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 
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Table A.123: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 







[26] 20.1 







1A 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


IB 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


c12 


c12 


[28] 7.2.2 


c13 


c13 


3 


Authentication-Info 


[26] 20.6 


c6 


c6 


[26] 20.6 


c7 


c7 


5 


Contact 


[26] 20.10 








[26] 20.10 


m 


m 


5A 


P-Associated-URI 


[52] 4.1 


c8 


c9 


[52] 4.1 


clO 


c11 


6 


Path 


[3514 


c3 


c3 


[3514 


c4 


c4 


8 


Service-Route 


[38] 5 


c5 


c5 


[38] 5 


c5 


c5 


9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF (A.3/4 AND A.4/2) THEN m ELSE n/a. - - S-CSCF acting as registrar. 

c2: IF A.3/4 OR A.3/1THEN m ELSE n/a. - - S-CSCF or UE. 

c3: IF A.4/24 THEN m ELSE n/a - - session initiation protocol extension header field for registering non- 
adjacent contacts. 

c4: IF A.4/24 THEN o ELSE n/a - - session initiation protocol extension header field for registering non-adjacent 
contacts. 

c5: IF A.4/28 THEN m ELSE n/a - - session initiation protocol extension header field for service route discovery 
during registration. 

c6: IF A.4/8 THEN o ELSE n/a - - authentication between UA and registrar. 

c7: IF A.4/8 THEN m ELSE n/a - - authentication between UA and registrar. 

c8: IF A.4/2 AND A.4/31 THEN m ELSE n/a - - P-Assocated-URI header extension and registrar. 

c9; IF A.3/1 AND A.4/31 THEN m ELSE n/a - - P-Assocated-URI header extension and S-CSCF. 

clO: IF A.4/31 THEN o ELSE n/a - - P-Assocated-URI header extension. 

c1 1 : IF A.4/31 AND A.3/1 THEN m ELSE n/a - - P-Assocated-URI header extension and UE. 

c12: IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

c13: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.123A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/103 OR A. 6/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.124: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 
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Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A. 6/14 - - Additional for 401 (Unauthorized) response 

Table A.125: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


Cl 


X 


[26] 20.27 


c1 


X 


6 


Security-Server 


[48] 2 


X 


X 


[48] 2 


n/a 


c2 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/8 THEN m ELSE n/a - - support of authentication between UA and registrar. 

c2: IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.I 26: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Retry-After 


[26] 20.33 








[26] 20.33 









Table A.I 27: Void 

Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.I 28: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Proxy-Authenticate 


[26] 20.27 


cl 


X 


[26] 20.27 


c1 


X 


9 


www-Authenticate 


[26] 20.44 








[26] 20.44 








cl : IF A.4/8 THEN m ELSE n/a - - support of authentication between UA and registrar. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.129: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 
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Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A. 6/27 - - Additional for 420 (Bad Extension) response 

Table A.130: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.130A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c2 


c2 


[48)2 


c1 


Cl 


c1 : IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
c2: IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 
and registrar. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/29 - - Additional for 423 (Interval Too Brief) response 

Table A.131 : Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Min-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


m 


m 



Table A.132: Void 

Prerequisite A.5/19 - - REGISTER response 

Table A.133: Supported message bodies within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1 .4.1 3 SUBSCRIBE method 

Prerequisite A.5/20 - - SUBSCRIBE request 



Table A.134: Supported headers within the SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Contact 


[56B] 9.2 


c22 


c22 


[56B] 9.2 


c26 


c26 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 








[28] 7.2.2 


m 


m 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


Expires 


[26] 20.19 


(note 1) 


(note 1) 


[26] 20.19 


m 


m 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16A 


History-Info 


[66] 4.1 


c25 


c25 


[66] 4.1 


c25 


c25 


17 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


18 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


18A 


Organization 


[26] 20.25 








[26] 20.25 








18B 


P-Access-Network-lnfo 


[52] 4.4 


c12 


c13 


[52] 4.4 


c12 


c14 


18C 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c6 


c6 


18D 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


clO 


clO 


18E 


P-Charging-Function- 
Addresses 


[52] 4.5 


c17 


c18 


[52] 4.5 


c17 


c18 


18F 


P-Charging-Vector 


[52] 4.6 


c15 


c16 


[52] 4.6 


c15 


c16 


18G 


P-Preferred-ldentity 


[34] 9.2 


c6 


c7 


[34] 9.2 


n/a 


n/a 


18H 


P-Profile-Key 


[97] 5 


n/a 


n/a 


[97] 5 


n/a 


n/a 


181 


P-User-Database 


[82] 4 


n/a 


n/a 


[82] 4 


n/a 


n/a 


18J 


P-Visited-Network-ID 


[52] 4.3 


X (note 2) 


X 


[52] 4.3 


c11 


n/a 


18K 


Privacy 


[33] 4.2 


c9 


c9 


[33] 4.2 


c9 


c9 


19 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


20 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


20A 


Reason 


[34A] 2 


c21 


c21 


[34A] 2 


c21 


c21 


21 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


m 


m 


21A 


Referred-By 


[5913 


c23 


c23 


[5913 


c24 


c24 


21B 


Reject-Contact 


[56B] 9.2 


c22 


c22 


[56B] 9.2 


c26 


c26 


21C 


Request-Disposition 


[56B] 9.1 


c22 


c22 


[56B] 9.1 


c26 


c26 


22 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


23 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


23A 


Security-Client 


[48] 2.3.1 


c19 


c19 


[481 2.3.1 


n/a 


n/a 


23B 


Security-Verify 


[48] 2.3.1 


c20 


c20 


[48] 2.3.1 


n/a 


n/a 


24 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


25 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 








[261 20.41 








28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c3: 
c4: 
c5: 
c6: 

c7: 

c8: 
c9: 
clO 
c11 
c12 
c13 
c14 

c15 
c16 
c17 
c18 
c19 
c20 
c21 
c22 
c23 
c24 
c25 

c26: 



IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 

IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 3). 

- security mechanism agreement for the session initiation protocol. 

- the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 
- an extension to the session initiation protocol for request history 



IF A.4/35 THEN ELSE n/a 
IFA.4/35THENm ELSE n/a 
IF A.4/37 THEN ELSE n/a 
IFA.4/37THENm ELSE n/a 
IF A.4/38 THEN ELSE n/a 
IF A.4/40 THEN ELSE n/a 
IF A.4/43 THEN m ELSE n/a 
IF A.4/43 THEN ELSE n/a 
IFA.4/47THENm ELSE n/a 
information. 
IF A.4/40 THEN m ELSE n/a 



- caller preferences for the session initiation protocol. 



NOTE 1 
NOTE 2 
NOTE 3 



The strength of this requirement is RECOMMENDED rather than OPTIONAL. 

The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 

Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 

defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/20 - - SUBSCRIBE request 

Table A.135: Supported message bodies within the SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/1 - - Additional for 100 (Trying) response 

Table A.135A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26120.14 


m 


m 


[26120.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


c1 


[26)20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
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Prerequisite A.5/21 - - SUBSCRIBE response for all status-codes 

Table A.136: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c12 


c12 


[26] 20.5 


m 


m 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26120.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c13 


c13 


[66] 4.1 


c13 


c13 


10 


IVIIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


Organization 


[26] 20.25 








[26] 20.25 








10B 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


10C 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


10D 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


c10 


c11 


10E 


P-Charging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


10F 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10G 


Privacy 


[33] 4.2 


c4 


c4 


[331 4.2 


c4 


c4 


10H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


10! 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

g2: if A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A. 4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
c4: IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c12: IF A.6/18 THEN m ELSE o - - 405 (Method Not Allowed). 
c13: IF A.4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 



Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/102 - - Additional for 2xx response 



Table A.137: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 








[28] 7.2.2 


m 


m 


1 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 
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2 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


m 


m 


4 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 ; IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 



Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.137A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/103 OR A.6/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.138: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Contact 


[26] 20.10 


m (note) 


m 


[26] 20.10 


m 


m 


NOTE: 


The strength of this requirement is RECOMMENDED rather than MANDATORY for a 485 response. 



Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A. 6/14 - - Additional for 401 (Unauthorized) response 

Table A.139: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.140: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 







[26] 20.33 
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Table A.141: Void 

Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.142: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Proxy-Autlienticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


c1 


c1 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite A. 6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.143: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


6 


Server 


[26] 20.35 








[26] 20.35 








0.1 At least one of these capabilities is supported. 



Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A. 6/27 - - Additional for 420 (Bad Extension) response 

Table A.144: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.144A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[4812 


X 


X 


[48] 2 


Cl 


cl 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 
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Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A. 6/29 - - Additional for 423 (Interval Too Brief) response 

Table A.145: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Min-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


m 


m 



Table A.I 46: Void 

Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/39 - - Additional for 489 (Bad Event) response 

Table A.147: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


m 


m 



Table A.1 48: Void 

Prerequisite A.5/21 - - SUBSCRIBE response 

Table A.149: Supported message bodies within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.14 UPDATE method 

Prerequisite A.5/22 - - UPDATE request 



Table A.I 50: Supported headers within the UPDATE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Contact 


[56B] 9.2 


c20 


c20 


[56B] 9.2 


c24 


c24 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


4 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


5 


Allow-Events 


[28] 7.2.2 


c2 


c2 


[28] 7.2.2 


c3 


c3 


6 


Authorization 


[26] 20.7 


c4 


c4 


[26] 20.7 


c4 


c4 


7 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Call-Info 


[26] 20.9 








[26] 20.9 








9 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


10 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


11 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


12 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


13 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


14 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


15 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


16 


Date 


[26] 20.17 


c5 


c5 


[26] 20.17 


m 


m 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


18 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


19 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


19A 


Min-SE 


[58] 5 


c21 


c21 


[58] 5 


c21 


c21 


20 


Organization 


[26] 20.25 








[26] 20.25 








20A 


P-Access-Network-lnfo 


[52] 4.4 


c11 


c12 


[52] 4.4 


c11 


c13 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c16 


c17 


[52] 4.5 


c16 


c17 


20C 


P-Charging-Vector 


[52] 4.6 


c14 


c15 


[52] 4.6 


c14 


c15 


20D 


Privacy 


[33] 4.2 


c6 


n/a 


[33] 4.2 


c6 


n/a 


21 


Proxy-Authorization 


[26] 20.28 


c10 


clO 


[26] 20.28 


n/a 


n/a 


22 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


22A 


Reason 


[34A] 2 


c8 


c8 


[34A] 2 


c8 


c8 


23 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


23A 


Referred-By 


[59] 3 


c22 


c22 


[59] 3 


c23 


c23 


23B 


Reject-Contact 


[56B] 9.2 


c20 


c20 


[56B] 9.2 


c24 


c24 


23C 


Request-Disposition 


[56B] 9.1 


c20 


c20 


[56B] 9.1 


c24 


c24 


24 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


25A 


Security-Client 


[48] 2.3.1 


c18 


c18 


[48] 2.3.1 


n/a 


n/a 


25B 


Security-Verify 


[48] 2.3.1 


c19 


c19 


[48] 2.3.1 


n/a 


n/a 


25C 


Session-Expires 


[5814 


c21 


c21 


[58] 4 


c21 


c21 


26 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


27 


Timestamp 


[26] 20.38 


c9 


c9 


[26] 20.38 


m 


m 


28 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


29 


User-Agent 


[26] 20.41 








[26] 20.41 








30 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c2: 
c3: 
c4: 
c5: 
c6: 
c8: 
c9: 
clO 
c11 
c12 
c13 

c14 
c15 
c16 
c17 
c18 
c19 
c20 
c21 
c22 
c23 
c24 



IF A.4/20 THEN ELSE n/a 
IFA.4/20THENm ELSE n/a 
IFA.4/7THENm ELSE n/a - 
IFA.4/11 THEN ELSE n/a 
IF A.4/26 THEN ELSE n/a 
IF A.4/38 THEN ELSE n/a 
IF A.4/6 THEN ELSE n/a - 



- SIP specific event notification extension. 

- SIP specific event notification extension, 
authentication between UA and UA. 

- insertion of date in requests and responses. 

- a privacy mechanism for the Session Initiation Protocol (SIP). 

- the Reason header field for the session initiation protocol, 
timestamping of requests. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note). 

- security mechanism agreement for the session initiation protocol. 

- caller preferences for the session initiation protocol. 

- the SIP session timer. 

- the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 
caller preferences for the session initiation protocol. 



IF A.4/35 THEN ELSE n/a - 
IFA.4/35THENm ELSE n/a ■ 
IF A.4/37 THEN ELSE n/a - 
IFA.4/37THENm ELSE n/a • 
IF A.4/40 THEN ELSE n/a - 
IFA.4/42THENm ELSE n/a ■ 
IF A.4/43 THEN m ELSE n/a ■ 
IF A.4/43 THEN ELSE n/a - 
IF A.4/40 THEN m ELSE n/a ■ 



NOTE: Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/22 - - UPDATE request 

Table A.151 : Supported message bodies within the UPDATE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.151 A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


c1 


[26)20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
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Prerequisite A.5/23 - - UPDATE response for all status-codes 



Table A.152: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c11 


c11 


[26] 20.5 


m 


m 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Gall-Info 


[26] 20.9 








[26] 20.9 








1B 


Contact 


[26] 20.10 








[26] 20.10 








2 


Content-Disposition 


[26120.11 








[26120.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


Organization 


[26] 20.25 








[26] 20.25 








10B 


P-Access-Network-lnfo 


[52] 4.4 


c4 


c5 


[521 4.4 


c4 


c6 


10C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


clO 


[52] 4.5 


c9 


ClO 


10D 


P-Charging-Vector 


[52] 4.6 


c7 


c8 


[52] 4.6 


c7 


c8 


10E 


Privacy 


[33] 4.2 


c3 


n/a 


[33] 4.2 


c3 


n/a 


10F 


Require 


[26] 20.31 


m 


m 


[261 20.31 


m 


m 


10G 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


c12 


c12 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

g2: if A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c4: if A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c5: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c6: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c7: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c8: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
clO; IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.6/1 8 THEN m ELSE o - - 405 (Method Not Allowed) 
c12: IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 


NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 



Prerequisite A.5/23 - - UPDATE response 
Prerequisite: A. 6/102 - - Additional for 2xx response 



Table A.153: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


OB 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


OC 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


1 


Allow-Events 


[28] 7.2.2 


c4 


c4 


[28] 7.2.2 


c5 


c5 


2 


Authentication-Info 


[26] 20.6 


cl 


cl 


[261 20.6 


c2 


c2 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


4 


Session-Expires 


[58] 


c3 


c3 


[58] 


c3 


c3 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



235 



ETSI TS 124 229 V7.6.0 (2006-12) 



Supported 



[26] 20.37 I m 



m 



[26] 20.37 I m 



m 



c1: IF A.4/7 THEN ELSE n/a-- 

c2: IF A.4/7 THEN m ELSE n/a- 

c3: IF A.4/42 THEN m ELSE n/a 

c4: IF A.4/20 THEN ELSE n/a - 

c5: IF A.4/20 THEN m ELSE n/a 



authentication between UA and UA. 
authentication between UA and UA. 

- the SIP session timer 

- SIP specific event notification extension. 

- SIP specific event notification extension. 



Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 

Table A.153A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/103 OR A. 6/35 - - Additional for 3xx, 485 (Ambiguous) response 

Table A.154: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Contact 


[26120.10 








[26120.10 









Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A. 6/14 - - Additional for 401 (Unauthorized) response 

Table A.154A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


cl 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.155: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.156: Void 

Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.157: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


4 


Proxy-Autlienticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


c1 


c1 


8 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.158: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 At least one of these capabilities is supported. 



Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.159: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.159A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


Cl 


cl 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 
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Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/28A - - Additional for 422 (Session Interval Too Small) response 

Table A.159B: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Min-SE 


[58] 5 


c1 


c1 


[58] 5 


c1 


Cl 


c1: 


IF A.4/42 THEN m ELSE n/a - - 


the SIP session timer. 











Table A.160: Void 

Prerequisite A.5/23 - - UPDATE response 

Table A.161 : Supported message bodies within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.2.2 Proxy role 
A.2.2.1 Introduction 

This subclause contains the ICS proforma tables related to the proxy role. They need to be completed only for proxy 
implementations. 

Prerequisite: A.2/2 - - proxy role 
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A.2.2.2 Major capabilities 



Table A.162: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC Status 


Profile status 




Capabilities within main protocol 








3 


initiate session release? 


[26] 16 


x 


c27 


4 


stateless proxy behaviour? 


[26] 16.11 


0.1 


c28 


5 


stateful proxy behaviour? 


[26] 16.2 


0.1 


c29 


6 


forking of initial requests? 


[26] 16.1 


c1 


c31 


7 


support of indication of TLS 
connections in the Record-Route 
header on the upstream side? 


[26] 16.7 





n/a 


8 


support of indication TLS connections 
in the Record-Route header on the 
downstream side? 


[26] 16.7 





n/a 


8A 


authentication between UA and proxy? 


[26] 20.28, 
22.3 





x 


9 


insertion of date in requests and 
responses? 


[26] 20.17 








10 


suppression or modification of alerting 
information data? 


[26] 20.4 








11 


reading the contents of the Require 
header before proxying the request or 
response? 


[26] 20.32 








12 


adding or modifying the contents of the 
Require header before proxying the 
REGISTER request or response 


[26] 20.32 





m 


13 


adding or modifying the contents of the 
Require header before proxying the 
request or response for methods other 
than REGISTER? 


[26] 20.32 








14 


being able to insert itself in the 
subsequent transactions in a dialog 
(record-routing)? 


[26] 16.6 





c2 


15 


the requirement to be able to use 
separate URIs in the upstream direction 
and downstream direction when record 
routeing? 


[26] 16.7 


c3 


c3 


16 


reading the contents of the Supported 
header before proxying the response? 


[26] 20.37 








17 


reading the contents of the 
Unsupported header before proxying 
the 420 response to a REGISTER? 


[26] 20.40 





m 


18 


reading the contents of the 
Unsupported header before proxying 
the 420 response to a method other 
than REGISTER? 


[26] 20.40 








19 


the inclusion of the Error-Info header in 
3xx - 6xx responses? 


[26] 20.18 








19A 


reading the contents of the 
Organization header before proxying 
the request or response? 


[26] 20.25 








19B 


adding or concatenating the 
Organization header before proxying 
the request or response? 


[26] 20.25 








19C 


reading the contents of the Call-Info 
header before proxying the request or 
response? 


[26] 20.25 








19D 


adding or concatenating the Call-Info 
header before proxying the request or 
response? 


[26] 20.25 








19E 


delete Contact headers from 3xx 
responses prior to relaying the 
response? 


[26] 20 










Extensions 
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20 


the SIP INFO method? 


[25] 








21 


reliability of provisional responses in 
SIP? 


[27] 





i 


22 


the REFER method? 


[36] 








23 


integration of resource management 
and SIP? 


[30] [64] 





i 


24 


the SIP UPDATE method? 


[29] 


c4 


i 


26 


SIP extensions for media authorization? 


[31] 





c7 


27 


SIP specific event notification 


[28] 





i 


28 


the use of NOTIFY to establish a dialog 


[28] 4.2 





n/a 


29 


Session Initiation Protocol Extension 
Header Field for Registering Non- 
Adjacent Contacts 


[35] 





c6 


30 


extensions to the Session Initiation 
Protocol (SIP) for asserted identity 
within trusted networks 


[34] 





m 


30A 


act as first entity within the trust domain 
for asserted identity 


[34] 


c5 


c8 


30B 


act as subsequent entity within trust 
network that can route outside the trust 
network 


[34] 


c5 


c9 


31 


a privacy mechanism for the Session 
Initiation Protocol (SIP) 


[33] 





m 


31A 


request of privacy by the inclusion of a 
Privacy header 


[33] 


n/a 


n/a 


31B 


application of privacy based on the 
received Privacy header 


[33] 


clO 


c12 


31C 


passing on of the Privacy header 
transparently 


[33] 


clO 


c13 


31D 


application of the privacy option 
"header" such that those headers which 
cannot be completely expunged of 
identifying information without the 
assistance of intermediaries are 
obscured? 


[33] 5.1 


X 


X 


31E 


application of the privacy option 
"session" such that anonymization for 
the session(s) initiated by this message 
occurs? 


[33] 5.2 


n/a 


n/a 


31 F 


application of the privacy option "user" 
such that user level privacy functions 
are provided by the network? 


[33] 5.3 


n/a 


n/a 


31G 


application of the privacy option "id" 
such that privacy of the network 
asserted identity is provided by the 
network? 


[34] 7 


c11 


c12 


31H 


application of the privacy option 
"history" such that privacy of the 
History-Info header is provided by the 
network? 


[66] 7.2 


c34 


c34 


32 


Session Initiation Protocol Extension 
Header Field for Service Route 
Discovery During Registration 


[38] 





c30 


33 


a messaging mechanism for the 
Session Initiation Protocol (SIP) 


[50] 





m 


34 


Compressing the Session Initiation 
Protocol 


[55] 





c7 


35 


private header extensions to the 
session initiation protocol for the 3rd- 
Generation Partnership Project 
(3GPP)? 


[52] 





m 


36 


the P-Associated-URI header 
extension? 


[52] 4.1 


c14 


c15 


37 


the P-Called-Party-ID header 
extension? 


[52] 4.2 


c14 


c16 


38 


the P-Visited-Network-ID header 
extension? 


[52] 4.3 


c14 


c17 
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39 


reading, or deleting tlie P-Visited- 
Networl<-ID header before proxying the 
request or response? 


[52] 4.3 


c18 


n/a 


41 


the P-Access-Networl<-lnfo header 
extension? 


[52] 4.4 


c14 


c19 


42 


act as first entity within the trust domain 
for access network information? 


[52] 4.4 


c20 


c21 


43 


act as subsequent entity within trust 
networl< for access networl< information 
that can route outside the trust 
networl<? 


[52] 4.4 


c20 


c22 


44 


the P-Charging-Function-Addresses 
header extension? 


[52] 4.5 


c14 


m 


44A 


adding, deleting or reading the P- 
Charging-Function-Addresses header 
before proxying the request or 
response? 


[52] 4.6 


c25 


c26 


45 


the P-Charging-Vector header 
extension? 


[52] 4.6 


c14 


m 


46 


adding, deleting, reading or modifying 
the P-Charging-Vector header before 
proxying the request or response? 


[52] 4.6 


c23 


c24 


47 


security mechanism agreement for the 
session initiation protocol? 


[48] 





c7 


48 


the Reason header field for the session 
initiation protocol 


[34A] 








49 


an extension to the session initiation 
protocol for symmetric response 
routeing 


[56A] 





X 


50 


caller preferences for the session 
initiation protocol? 


[568] 


c33 


c33 


50A 


the proxy-directive within caller- 
preferences? 


[568] 9.1 


0.4 


0.4 


50B 


the cancel-directive within caller- 
preferences? 


[568] 9.1 


0.4 


0.4 


50C 


the fork-directive within caller- 
preferences? 


[568] 9.1 


0.4 


c32 


SOD 


the recurse-directive within caller- 
preferences? 


[568] 9.1 


0.4 


0.4 


50E 


the parallel-directive within caller- 
preferences? 


[568] 9.1 


0.4 


c32 


50F 


the queue-directive within caller- 
preferences? 


[568] 9.1 


0.4 


0.4 


51 


an event state publication extension to 
the session initiation protocol? 


[70] 





m 


52 


SIP session timer? 


[58] 








53 


the SIP Referred-By mechanism? 


[59] 








54 


the Session Inititation Protocol (SIP) 
"Replaces" header? 


[60] 








55 


the Session Inititation Protocol (SIP) 
"Join" header? 


[61] 








56 


the callee capabillities? 


[62] 








57 


an extension to the session initiation 
protocol for request history information? 


[66] 








58 


Rejecting anonymous requests in the 
session initiation protocol? 


[67] 








59 


session initiation protocol URIs for 
applications such as voicemail and 
interactive voice response 


[68] 








60 


the P-User-Database private header 
extension? 


[82] 








61 


Session initiation protocol's non-INVITE 
transactions? 


[83] 


m 


m 


62 


a uniform resource name for services 


[69] 


n/a 


c35 


63 


obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


[93] 





c36 


64 


an extension to the session initiation 


[95] 





c37 
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protocol for request cpc information? 








65 


the Stream Control Transmission 
Protocol (SCTP) as a Transport for the 
Session Initiation Protocol (SIP)? 


[96] 





{note2) 


66 


the SIP P-Profle-Key private header 
extension? 


[97] 





c41 


66A 


making the first query to the database 
in order to populate the P-Profile-Key 
header? 


[97] 


c38 


c39 


66B 


using the information in the P-Profile- 
Key header? 


[97] 


c38 


c40 
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c1: 
c2: 
c3: 

c4: 
c5: 

c6: 
c7: 
c8: 

c9: 



clO: 

c11: 

c12: 
c13: 

c14: 

c15: 

c16: 

c17: 



c18: 
c19: 



c20: 
c21: 

c22: 

c23 
c24 
c25 

c26: 

c27 
c28 
c29 
c30 
c31 
c32 
c33 



c34: 

c35 
c36 
c37 

c38: 
c39: 

c40: 

c41: 

0.1 

0.2 
0.3 
0.4 



IF A.162/5 THEN o ELSE n/a - - stateful proxy behaviour. 

IF A.3/2 OR A.3/3A OR A.3/4 THEN m ELSE o - - P-CSCF, l-CSCF{THIG) or S-CSCF. 

IF (A.1 62/7 AND NOT A.1 62/8) OR (NOT A.1 62/7 AND A.1 62/8) THEN m ELSE IF 

A. 162/1 4 THEN o ELSE n/a - - TLS interworking with non-TLS else proxy insertion. 

IF A. 162/23 THEN m ELSE o - - integration of resource management and SIP. 

IF A.162/30 THEN o ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks. 

IF A.3/2 OR A.3/3A THEN m ELSE n/a - - P-CSCF or l-CSCF (THIG). 

IF A.3/2 THEN m ELSE n/a - - P-CSCF. 

IF A.3/2 AND A.162/30 THEN m ELSE n/a - - P-CSCF and extensions to the Session 

Initiation Protocol (SIP) for asserted identity within trusted networks. 

IF A.3/2 AND A.1 62/30 THEN m ELSE IF A.3/7C AND A.162/30 THEN o ELSE n/a - - 

S-CSCF or AS acting as proxy and extensions to the Session Initiation Protocol (SIP) 

for asserted identity within trusted networks (NOTE 1). 

IF A. 162/31 THEN 0.2 ELSE n/a - - a privacy mechanism for the Session Initiation 

Protocol (SIP). 

IF A.162/31 B THEN o ELSE x - - application of privacy based on the received Privacy 

header. 

IF A.162/31 AND A.3/4 THEN m ELSE n/a - - S-CSCF. 

IF A.162/31 AND (A.3/2 OR A.3/3 OR A.3/7C) THEN m ELSE n/a - - P-CSCF OR I- 

CSCF OR AS acting as a SIP proxy. 

IF A. 162/35 THEN 0.3 ELSE n/a - - private header extensions to the session initiation 

protocol for the 3rd-Generation Partnership Project (3GPP). 

IF A.1 62/35 AND (A.3/2 OR A.3/3) THEN m THEN o ELSE n/a - - private header 

extensions to the session initiation protocol for the 3rd-Generation Partnership Project 

(3GPP) and P-CSCF or l-CSCF. 

IF A.1 62/35 AND (A.3/2 OR A.3/3 OR A.3/4) THEN m ELSE n/a - - private header 

extensions to the session initiation protocol for the 3rd-Generation Partnership Project 

(3GPP) and P-CSCF or l-CSCF or S-CSCF. 

IF A.162/35 AND (A.3/2 OR A.3/3) THEN m ELSE n/a - - private header extensions to 

the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and 

P-CSCF or l-CSCF. 

IF A.1 62/38 THEN o ELSE n/a - - the P-Visited-Network-ID header extension. 

IF A.162/35 AND (A.3/2 OR A.3.3 OR A.3/4 OR A.3/7 THEN m ELSE n/a - - private 

header extensions to the session initiation protocol for the 3rd-Generation Partnership 

Project (3GPP) and P-CSCF, l-CSCF, S-CSCF, AS acting as a proxy. 

IF A.1 62/41 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

IF A.162/41 AND A.3/2 THEN m ELSE n/a - - the P-Access-Network-lnfo header 

extension and P-CSCF. 

IF A.162/41 AND A.3/4 THEN m ELSE n/a - - the P-Access-Network-lnfo header 

extension and S-CSCF. 

- the P-Charging-Vector header extension. 

- the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header 



IF A.162/45 THEN o ELSE n/a ■ 

IF A.162/45 THEN m ELSE n/a 

IF A.1 62/44 THEN o ELSE n/a ■ 

extension. 

IF A.162/44 THEN m ELSE n/a 

extension. 

IF A.3/2 OR A.3/4 THEN m ELSE x 



the P-Charging-Function Addresses header 



P-CSCF or S-CSCF. 



P-CSCF or S-CSCF of IVIGCF. 
P-CSCF or S-CSCF of MGCF. 



IF A.3/2 OR A.3/4 OR A.3/6 then m ELSE o - ■ 

IF A.3/2 OR A.3/4 OR A.3/6 then o ELSE m - ■ 

IFA.3/2oELSEi-- P-CSCF. 

IF A.3/4 THEN m ELSE x - - S-CSCF. 

IF A.3/4 THEN m ELSE 0.4 - - S-CSCF. 

IF A.162/50A OR A.162/50B OR A.162/50C OR A.162/50D OR A.162/50E OR 

A.162/50F THEN m ELSE n/a - - support of any directives within caller preferences for 

the session initiation protocol. 

IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for 

request history information. 

IF A.3/2 OR A.3/1 1 THEN m ELSE n/a - - P-CSCF, E-CSCF. 

IF A.3/4 THEN m ELSE n/a - - S-CSCF. 

IF A.3/2 OR A.3/3 OR A.3/4 OR A.3.5 OR A.3/6 OR A.3/7 OR A.3/8 THEN o ELSE n/a 

- - cpc URI parameter. 

IF A. 162/66 THEN o ELSE n/a - - the SIP P-Profile-Key private header. 

IF A.1 62/66 AND A.3/3 THEN m ELSE n/a - - the SIP P-Profile-Key private header, I- 

CSCF. 

IF A.1 62/66 AND A.3/4 THEN m ELSE n/a - - the SIP P-Profile-Key private header, S- 

CSCF. 

IF A.3/3 OR A.3/4 THEN o ELSE n/a - - l-CSCF, S-CSCF. 

It is mandatory to support at least one of these items. 

It is mandatory to support at least one of these items. 

It is mandatory to support at least one of these items. 

At least one of these capabilities is sup ported . 



m 
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NOTE 1 : An AS acting as a proxy may be outside tlie trust domain, and therefore not able to 
support the capability for that reason; in this case it is perfectly reasonable for the 
header to be passed on transparently, as specified in the PDU parts of the profile. 

NOTE 2: Not applicable over Gm reference point (UE - P-CSCF). 



A.2.2.3 PDUs 



Table A.163: Supported methods 



Item 


PDU 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


ACK request 


[26] 13 


m 


m 


[26] 13 


m 


m 


2 


BYE request 


[26] 16 


m 


m 


[26] 16 


m 


m 


3 


BYE response 


[26] 16 


m 


m 


[26] 16 


m 


m 


4 


CANCEL request 


[26] 16.10 


m 


m 


[26] 16.10 


m 


m 


5 


CANCEL response 


[26)16.10 


m 


m 


[26] 16.10 


m 


m 


8 


INVITE request 


[26] 16 


m 


m 


[26] 16 


m 


m 


9 


INVITE response 


[26] 16 


m 


m 


[26] 16 


m 


m 


9A 


MESSAGE request 


[50] 4 


c5 


c5 


[50)7 


c5 


c5 


9B 


MESSAGE response 


[50] 4 


c5 


c5 


[50] 7 


c5 


c5 


10 


NOTIFY request 


[28)8.1.2 


c3 


c3 


[28)8.1.2 


c3 


c3 


11 


NOTIFY response 


[28)8.1.2 


c3 


c3 


[28)8.1.2 


c3 


c3 


12 


OPTIONS request 


[26] 16 


m 


m 


[26] 16 


m 


m 


13 


OPTIONS response 


[26] 16 


m 


m 


[26] 16 


m 


m 


14 


PRACK request 


[27] 6 


c6 


c6 


[27)6 


c6 


c6 


15 


PRACK response 


[27)6 


c6 


c6 


[27] 6 


c6 


c6 


15A 


PUBLISH request 


[70) 
11.1.1 


c20 


c20 


[70] 
11.1.1 


c20 


c20 


15B 


PUBLISH response 


[70) 
11.1.1 


c20 


c20 


[70] 
11.1.1 


c20 


c20 


16 


REFER request 


[36] 3 


c1 


cl 


[36)3 


c1 


cl 


17 


REFER response 


[36)3 


Cl 


cl 


[36)3 


c1 


cl 


18 


REGISTER request 


[26] 16 


m 


m 


[26) 16 


m 


m 


19 


REGISTER response 


[26] 16 


m 


m 


[26) 16 


m 


m 


20 


SUBSCRIBE request 


[28] 8.1.1 


c3 


c3 


[28] 8.1.1 


c3 


c3 


21 


SUBSCRIBE response 


[28] 8.1.1 


c3 


c3 


[28)8.1.1 


c3 


c3 


22 


UPDATE request 


[29)7 


c4 


c4 


[29)7 


c4 


c4 


23 


UPDATE response 


[29)7 


c4 


c4 


[29)7 


c4 


c4 


c1 : IF A.162/22 THEN m ELSE n/a - - the REFER method. 

c3 IF A.162/27 THEN m ELSE n/a - - SIP specific event notification. 

c4 IF A.162/24 THEN m ELSE n/a - - the SIP UPDATE method. 

c5: IF A. 162/33 THEN m ELSE n/a - - the SIP MESSAGE method. 

c6: IF A. 162/21 THEN m ELSE n/a - - reliability of provisional responses. 

c20; IF A.4/51 THEN m ELSE n/a 
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A.2.2.4 PDU parameters 



A.2.2.4.1 



Status-codes 



Table A.164: Supported-status codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


100 (Trying) 


[26] 
21.1.1 


Cl 


cl 


[26] 
21.1.1 


c2 


c2 


101 


Ixx response 


[26] 21.1 


p21 


p21 


[26] 21.1 


p21 


p21 


2 


180 (Ringing) 


[26] 
21.1.2 


c3 


c3 


[26] 
21.1.2 


c3 


c3 


3 


181 (Call Is Being Forwarded) 


[26] 
21.1.3 


c3 


c3 


[26] 
21.1.3 


c3 


c3 


4 


182 (Queued) 


[26] 
21.1.4 


c3 


c3 


[26] 
21.1.4 


c3 


c3 


5 


183 (Session Progress) 


[26] 
21.1.5 


c3 


c3 


[26] 
21.1.5 


c3 


c3 


102 


2xx response 


[26] 21 .2 


p22 


p22 


[26] 21.1 


p22 


p22 


6 


200 (OK) 


[26] 
21.2.1 


m 


m 


[26] 
21.2.1 


i 


m 


7 


202 (Accepted) 


[28] 8.3.1 


c4 


c4 


[28] 8.3.1 


c4 


c4 


103 


3xx response 


[26] 21 .3 


p23 


p23 


[26] 21.1 


p23 


p23 


8 


300 (l\/lultiple Choices) 


[26] 
21.3.1 


m 


m 


[26] 
21.3.1 






9 


301 (IVIoved Permanently) 


[26] 
21.3.2 


m 


m 


[26] 
21.3.2 






10 


302 (IVIoved Temporarily) 


[26] 
21.3.3 


m 


m 


[26] 
21.3.3 






11 


305 (Use Proxy) 


[26] 
21.3.4 


m 


m 


[26] 
21.3.4 






12 


380 (Alternative Service) 


[26] 
21.3.5 


m 


m 


[26] 
21.3.5 






104 


4xx response 


[26] 21 .4 


p24 


p24 


[26] 21 .4 


p24 


p24 


13 


400 (Bad Request) 


[26] 
21.4.1 


m 


m 


[26] 

21.4.1 


i 


i 


14 


401 (Unauthorized) 


[26] 
21.4.2 


m 


m 


[26] 
21.4.2 


i 


clO 


15 


402 (Payment Required) 


[26] 
21.4.3 


n/a 


n/a 


[26] 
21.4.3 


n/a 


n/a 


16 


403 (Forbidden) 


[26] 
21.4.4 


m 


m 


[26] 
21.4.4 






17 


404 (Not Found) 


[26] 
21.4.5 


m 


m 


[26] 
21.4.5 






18 


405 (IVIethod Not Allowed) 


[26] 
21.4.6 


m 


m 


[26] 
21.4.6 






19 


406 (Not Acceptable) 


[26] 
21.4.7 


m 


m 


[26] 
21.4.7 






20 


407 (Proxy Authentication 
Required) 


[26] 
21.4.8 


m 


m 


[26] 
21.4.8 






21 


408 (Request Timeout) 


[26] 
21.4.9 


c3 


c3 


[26] 
21.4.9 






22 


410 (Gone) 


[26] 
21.4.10 


m 


m 


[26] 
21.4.10 






22A 


412 (Conditional Request 
Failed) 


[70] 
11.2.1 


c20 


c20 


[70] 
11.2.1 


c19 


c19 


23 


413 (Request Entity Too 
Large) 


[26] 
21.4.11 


m 


m 


[26] 
21.4.11 






24 


414 (Request-URI Too Large) 


[26] 
21.4.12 


m 


m 


[26] 
21.4.12 






25 


415 (Unsupported Media 
Type) 


[26] 
21.4.13 


m 


m 


[26] 

21.4.13 






26 


416 (Unsupported URI 


[26] 


m 


m 


[26] 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 




Scheme) 


21.4.14 






21.4.14 






27 


420 (Bad Extension) 


[26] 
21.4.15 


m 


m 


[26] 

21.4.15 


i 


i 


28 


421 (Extension Required) 


[26] 
21.4.16 


m 


m 


[26] 
21.4.16 


i 


i 


28A 


422 (Session Interval Too 
Small) 


[58] 6 


c8 


c8 


[58] 6 


c8 


c8 


29 


423 (Interval Too Brief) 


[26] 
21.4.17 


c5 


c5 


[26] 

21.4.17 


c6 


c6 


29A 


429 (Provide Referrer Identity) 


[59] 5 


c9 


c9 


[59] 5 


c9 


c9 


29B 


433 (Anonymity Disallowed) 


[67] 4 


c14 


c14 


[67] 4 


c14 


c14 


30 


480 (Temporarily not 
available) 


[26] 
21.4.18 


m 


m 


[26] 
21.4.18 






31 


481 (Call /Transaction Does 
Not Exist) 


[26] 
21.4.19 


m 


m 


[26] 
21.4.19 






32 


482 (Loop Detected) 


[26] 
21.4.20 


m 


m 


[26] 
21.4.20 






33 


483 (Too Many Hops) 


[26] 
21.4.21 


m 


m 


[26] 
21.4.21 






34 


484 (Address Incomplete) 


[26] 
21.4.22 


m 


m 


[26] 
21.4.22 






35 


485 (Ambiguous) 


[26] 
21.4.23 


m 


m 


[26] 
21.4.23 






36 


486 (Busy Here) 


[26] 
21.4.24 


m 


m 


[26] 
21.4.24 






37 


487 (Request Terminated) 


[26] 
21.4.25 


m 


m 


[26] 
21.4.25 






38 


488 (Not Acceptable Here) 


[26] 
21.4.26 


m 


m 


[26] 
21.4.26 






39 


489 (Bad Event) 


[28] 7.3.2 


c4 


c4 


[28] 7.3.2 


c4 


c4 


40 


491 (Request Pending) 


[26] 
21.4.27 


m 


m 


[26] 
21.4.27 


i 


i 


41 


493 (Undecipherable) 


[26] 
21.4.28 


m 


m 


[26] 
21.4.28 


i 


i 


41A 


494 (Security Agreement 
Required) 


[48] 2 


c7 


c7 


[48] 2 


n/a 


n/a 


105 


5xx response 


[261 21 .5 


p25 


p25 


[26121.5 


p25 


p25 


42 


500 (Internal Server Error) 


[26] 
21.5.1 


m 


m 


[26] 
21.5.1 






43 


501 (Not Implemented) 


[26] 
21.5.2 


m 


m 


[26] 
21.5.2 






44 


502 (Bad Gateway) 


[26] 
21.5.3 


m 


m 


[26] 
21.5.3 






45 


503 (Service Unavailable) 


[26] 
21.5.4 


m 


m 


[26] 
21.5.4 






46 


504 (Server Time-out) 


[26] 
21.5.5 


m 


m 


[26] 
21.5.5 






47 


505 (Version not supported) 


[26] 
21.5.6 


m 


m 


[26] 
21.5.6 






48 


513 (Message Too Large) 


[26] 
21.5.7 


m 


m 


[26] 
21.5.7 






49 


580 (Precondition Failure) 


[30] 8 


m 


m 


[30] 8 






106 


6xx response 


[26] 21 .6 


p26 


p26 


[26121.6 


p26 


p26 


50 


600 (Busy Everywhere) 


[26] 
21.6.1 


m 


m 


[26] 
21.6.1 






51 


603 (Decline) 


[26] 
21.6.2 


m 


m 


[26] 
21.6.2 






52 


604 (Does Not Exist 
Anywhere) 


[26] 
21.6.3 


m 


m 


[26] 
21.6.3 






53 


606 (Not Acceptable) 


[26] 
21.6.4 


m 


m 


[26] 
21.6.4 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



c1: 



c2: 



c3: 

c4: 

c5: 

c6: 

c7: 

c8: 

c9: 

c10 

c14 

c19: 

c20: 

p21 

p22 

p23 

p24 



p25: 
p26: 



IF A. 163/3 OR A. 163/9 OR A.163/9B OR A. 163/11 OR A. 163/1 3 OR A. 163/1 5 OR A.I 63/1 5B OR A. 163/1 7 

OR A.163/19 OR A.163/21 OR A.163/23 AND A.162/5 THEN m ELSE n/a - - BYE response or INVITE 

response or MESSAGE response or NOTIFY response or OPTIONS response or PRACK response or 

PUBLISH response or REFER response or REGISTER response or SUBSCRIBE response or UPDATE 

response, stateful proxy. 

IF A. 163/3 OR A.I 63/9 OR A.163/9B OR A. 163/11 OR A. 163/1 3 OR A. 163/1 5 OR A.I 63/1 5B OR A. 163/1 7 

OR A.163/19 OR A.163/21 OR A.163/23 THEN (IF A.162/5 THEN m ELSE i) ELSE n/a - - BYE response or 

INVITE response or MESSAGE response or NOTIFY response or OPTIONS response or PRACK response 

or PUBLISH response or REFER response or REGISTER response or SUBSCRIBE response or UPDATE 

response, stateful proxy. 

IF A.163/9 THEN m ELSE n/a - - INVITE response. 

IF A.162/27 THEN m ELSE n/a - - SIP specific event notification. 

IF A.163/19 OR A.163/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE response. 

IF A.163/19 OR A.163/21 THEN i ELSE n/a - - REGISTER response or SUBSCRIBE response. 

IF A.162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

IF A.162/52 THEN m ELSE n/a - - the SIP session timer. 

IF A.162/53 AND A.163/17 THEN m ELSE n/a - - the SIP Referred-By mechanism and REFER response. 

IF A.3/2 THEN m ELSE i - - P-CSCF. 

IF A.4/48 THEN m ELSE n/a - - rejecting anonymous requests in the session initiation protocol. 

IF A.162/51 THEN i ELSE n/a - - an event state publication extension to the session initiation protocol. 

IF A.162/51 THEN m ELSE n/a - - an event state publication extension to the session initiation protocol. 

A. 164/2 OR A. 164/3 OR A. 164/4 OR A. 164/5 - - Ixx response 

A. 164/6 OR A. 164/7 - - 2xx response 

A. 164/8 OR A. 164/9 OR A. 164/10 OR A. 164/11 OR A. 164/1 2 OR A. 164/1 3 - - 3xx response 

A.164/14ORA.164/15ORA.164/16ORA.164/17ORA.164/18ORA.164/19ORA.164/20ORA.164/21 

OR A. 164/22 OR A.164/22A OR A. 164/23 OR A. 164/24 OR A. 164/25 OR A. 164/26 OR A. 164/27 OR 

A. 164/28 OR A.164/28A OR A. 164/29 OR A.164/29A OR A.164/29B OR A. 164/30 OR A. 164/31 OR 

A. 164/32 OR A. 164/33 OR A. 164/34 OR A. 164/35 OR A. 164/36 OR A. 164/436 OR A. 164/38 OR A. 164/39 

OR A.1 64/40 OR A.1 64/41 OR A.164/41A. - - 4xx response 

A. 164/42 OR A.1 64/43 OR A. 164/44 OR A. 164/45 OR A.1 64/46 OR A.1 64/47 OR A. 164/48 OR A.1 64/49 - - 

5xx response 

A.164/50 OR A.164/51 OR A.164/52 OR A.164/53 - - 6xx response 
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Table A.165: Supported headers within the ACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept-Gontact 


[56B] 9.2 


clO 


ClO 


[56B] 9.2 


c11 


oil 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 






7 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 






8 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 






9 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


10 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


c3 


11 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


12 


Date 


[26)20.17 


m 


m 


[26)20.17 


c2 


c2 


13 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


14 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


15 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


15A 


Privacy 


[33] 4.2 


c6 


c6 


[33) 4.2 


c7 


c7 


16 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


17 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


17A 


Reason 


[34A) 2 


c8 


c8 


[34A) 2 


c9 


c9 


17B 


Reject-Contact 


[56B] 9.2 


c10 


ClO 


[56B] 9.2 


c11 


oil 


17C 


Request-Disposition 


[56B] 9.1 


c10 


clO 


[56B] 9.1 


oil 


c11 


18 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


19 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


20 


Timestamp 


[26) 20.38 


m 


m 


[26) 20.38 


i 


i 


21 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


22 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


23 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A. 162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c7: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 
c9: IF A.I 62/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 
clO: IF A.I 62/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 
c1 1 : IF A. 162/50 THEN i ELSE n/a - - caller preferences for the session initiation protocol. 


NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Editor's note: Is the following table a suitable way of showing the contents of message bodies. 
Prerequisite A. 163/1 - - ACK request 

Table A.1 66: Supported message bodies within the ACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.3 BYE method 

Prerequisite A. 163/2 - - BYE request 



Table A.I 67: Supported headers within the BYE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


1A 


Accept-Contact 


[56B] 9.2 


c22 


c22 


[56B] 9.2 


c23 


c23 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


1 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 




c3 


8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 




c3 


9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 




c3 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


16 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


16B 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[34] 9.1 


c10 


clO 


16C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c17 


c17 


[52] 4.5 


c18 


c18 


16D 


P-Charging-Vector 


[52] 4.6 


c15 


n/a 


[52] 4.6 


c16 


n/a 


16E 


P-Preferred-ldentity 


[34] 9.2 


x 


X 


[34] 9.2 


c8 


n/a 


16F 


Privacy 


[33] 4.2 


c11 


c11 


[33] 4.2 


c12 


c12 


17 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


18 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


18A 


Reason 


[34A] 2 


c20 


c20 


[34A] 2 


c21 


c21 


19 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


19A 


Referred-By 


[59] 3 


c24 


c24 


[59] 3 


c25 


c25 


19B 


Reject-Contact 


[56B] 9.2 


c22 


c22 


[56B] 9.2 


c23 


c23 


19C 


Request-Disposition 


[56B] 9.1 


c22 


c22 


[56B] 9.1 


c23 


c23 


20 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


21 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


21A 


Security-Client 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c19 


c19 


21 B 


Security-Verify 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c19 


c19 


22 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


23 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


24 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


25 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


26 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 
c8: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c9: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
clO: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network, 
oil: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c12: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c15: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c16; IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c17: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c18: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c19: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
c20: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 
c21: IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 
c22: IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 
c23: IF A. 162/50 THEN i ELSE n/a - - caller preferences for the session initiation protocol. 
c24: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 
c25: IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 



NOTE; c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/2 - - BYE request 

Table A.168: Supported message bodies within the BYE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Table A.169: Void 

Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.169A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
g2: if A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/3 - - BYE response 



Table A.170: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


1 


i 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




c2 


3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




c2 


4 


Content-Language 


[26120.13 


m 


m 


[26)20.13 




c2 


5 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26)20.15 


i 


c2 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


1 


c2 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


10B 


P-Asserted-ldentity 


[34] 9.1 


c4 


c4 


[34) 9.1 


c5 


c5 


10C 


P-Charging-Function- 
Addresses 


[52) 4.5 


clO 


ClO 


[52) 4.5 


c11 


c11 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


n/a 


[52] 4.6 


c9 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10F 


Privacy 


[33] 4.2 


c6 


c6 


[33) 4.2 


c7 


c7 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


10H 


Server 


[26] 20.35 


m 


m 


[26) 20.35 


i 


i 


11 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


1 


i 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


1 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

g2: if A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c3: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A. 162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c5: IF A.162/30A or A.162/30B THEN m ELSE 1 - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c6: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c7: IF A.162/31D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
clO: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c11: IF A.I 62/44A THEN m ELSE IF A.I 62/44 THEN 1 ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c12: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c13: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c14: IF A.162/11 OR A.1 62/1 3 THEN m ELSE i-- reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/102 - - Additional for 2xx response 

Table A.1 71 : Supported headers within the BYE response 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


i 


Cl 


1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.171 A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/3 - BYE response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.172: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Contact 


[26] 20.10 


m 


m 


[26)20.10 


cl 


cl 


cl: 


IFA.162/19ETHENm 


ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.173: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.174: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



253 



ETSI TS 124 229 V7.6.0 (2006-12) 



Table A.175: Void 

Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.176: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.177: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.178: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.178A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
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Table A.179: Void 

Prerequisite A. 163/3 - - BYE response 

Table A.180: Supported message bodies within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.2.2.4.4 CANCEL method 

Prerequisite A. 163/4 - - CANCEL request 



Table A.181 : Supported headers within the CANCEL request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept-Contact 


[56B1 9.2 


clO 


ClO 


[56B1 9.2 


c11 


oil 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


9 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


10 


Date 


[26)20.17 


m 


m 


[26)20.17 


c2 


c2 


11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


12 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


14 


Privacy 


[33] 4.2 


c3 


c3 


[33) 4.2 


c4 


c4 


15 


Reason 


[34A) 2 


c8 


c8 


[34A] 2 


c9 


c9 


16 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


17 


Reject-Contact 


[56B] 9.2 


c10 


ClO 


[56B] 9.2 


c11 


oil 


17A 


Request-Disposition 


[56B] 9.1 


c10 


clO 


[56B] 9.1 


c11 


c11 


18 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


19 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


20 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


1 


21 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


22 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


23 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

g3: if a. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c4: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/14THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 
c8: IF A.162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 
c9: IF A.162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 
clO: IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 
c1 1 : IF A.162/50 THEN i ELSE n/a - - caller preferences for the session initiation protocol. 


NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/4 - - CANCEL request 

Table A.1 82: Supported message bodies within the CANCEL request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/5 - - CANCEL response for all status-codes 



Table A.183: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


5A 


Privacy 


[33] 4.2 


c2 


c2 


[33) 4.2 


c3 


c3 


6 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


7 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7A 


User-Agent 


[26] 20.41 







[26) 20.41 







8 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


9 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 
c2: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c3: IF A.162/31 D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 



Prerequisite A. 163/5 - - CANCEL response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.184: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/5 - - CANCEL response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.184A: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26)20.18 


m 


m 


[26)20.18 


i 


i 



Table A.1 85: Void 



Prerequisite A. 163/5 - - CANCEL response 



Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/42 OR A.164/45 OR A.164/50 OR A.164/51 - - 
Additional for Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal Server Error), 503 
(Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.186: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 
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Table A.I 88: Void 

Prerequisite A. 163/5 - - CANCEL response 

Table A.189: Supported message bodies within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.5 

Void 

A.2.2.4.6 

Void 



COMET method 



INFO method 



A.2.2.4.7 INVITE method 

Prerequisite A. 163/8 - - INVITE request 



Table A.204: Supported headers within the INVITE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


1A 


Accept-Contact 


[56B] 9.2 


c34 


c34 


[56B] 9.2 


c34 


c35 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


1 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


4 


Alert- Info 


[26] 20.4 


c2 


c2 


[26] 20.4 


c3 


c3 


5 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


6 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


8 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


9 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


10 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c12 


c12 


11 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 




i 


12 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 




c6 


13 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 




c6 


14 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 




c6 


15 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


16 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c6 


17 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


18 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c4 


c4 


19 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


20 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


20A 


History-Info 


[66] 4.1 


c43 


c43 


[66] 4.1 


c43 


c43 


21 


In-Reply-To 


[26] 20.21 


m 


m 


[26] 20.21 


i 


i 


21A 


Join 


[61] 7.1 


c41 


c41 


[61] 7.1 


c42 


c42 


22 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


23 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c6 


23A 


Min-SE 


[58] 5 








[58] 5 








24 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c5 


c5 


24A 


P-Access-Network-lnfo 


[52] 4.4 


c28 


c28 


[52] 4.4 


c29 


c30 


24B 


P-Asserted-ldentity 


[34] 9.1 


c15 


c15 


[34] 9.1 


c16 


c16 


24C 


P-Called-Party-ID 


[52] 4.2 


c19 


c19 


[52] 4.2 


c20 


c21 


24D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c26 


c27 


[52] 4.5 


c26 


c27 


24E 


P-Charging-Vector 


[52] 4.6 


c24 


c24 


[52] 4.6 


c25 


c25 


25 


P-Media-Authorization 


[31] 5.1 


c9 


clO 


[31] 5.1 


n/a 


n/a 


25A 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c14 


c14 


25B 


P-Profile-Key 


[9715 


c45 


c45 


[9715 


c46 


c46 


25C 


P-User-Database 


[82] 4 


c44 


c44 


[8214 


c44 


c44 


25D 


P-Visited-Network-ID 


[52] 4.3 


c22 


n/a 


[52] 4.3 


c23 


n/a 


26 


Priority 


[26] 20.26 


m 


m 


[26] 20.26 


i 


1 


26A 


Privacy 


[33] 4.2 


c17 


c17 


[33] 4.2 


c18 


c18 


27 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c13 


c13 


28 


Proxy-Require 


[26] 
20.29, 
[34] 4 


m 


m 


[26] 
20.29, 
[34] 4 


m 


m 


28A 


Reason 


[34A] 2 


c32 


c32 


[34A] 2 


c33 


c33 


29 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c11 


c11 


30 


Referred-By 


[59] 3 


c37 


c37 


[59] 3 


c38 


c38 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


31 


Reject-Contact 


[568] 9.2 


c34 


c34 


[56B] 9.2 


c34 


c35 


31A 


Replaces 


[60] 6.1 


c39 


c39 


[60] 6.1 


c40 


c40 


31B 


Reply-To 


[26] 20.31 


m 


m 


[26] 20.31 


i 


i 


31B 


Request-Disposition 


[56B] 9.1 


c34 


c34 


[568] 9.1 


c34 


c34 


32 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c7 


c7 


33 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


33A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c31 


c31 


33B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c31 


c31 


33C 


Session-Expires 


[58] 4 


c36 


c36 


[58] 4 


c36 


c36 


34 


Subject 


[26] 20.36 


m 


m 


[26] 20.36 


i 




35 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c8 


c8 


36 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 




37 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


38 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 




39 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



c1: 
c2: 
c3: 
c4: 
c5: 
c6: 
c7: 



c8: 

c9: 

clO: 

c11: 

c12 
c13 
c14 
c15 

c16: 



c17: 
c18: 

c19 
c20 
c21 

c22: 
c23: 

c24: 
c25: 



c26: 
c27: 



c28: 



c29: 



c30: 



c31 
c32 
c33 
c34 
c35 

c36 
c37 
c38 
c39 
c40 
c41 
c42 
c43 

c44: 
c45: 

c46: 



IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

IF A.162/10 THEN n/a ELSE m - - suppression or modification of alerting information data. 

IF A.162/10 THEN m ELSE i - - suppression or modification of alerting information data. 

IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 

IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

IF A.162/26 THEN m ELSE n/a - - SIP extensions for media authorization. 

IF A.3/2 THEN m ELSE n/a - - P-CSCF. 

IF A.I 62/1 4 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 

IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 

IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 

IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 

IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

IF A.162/37 AND A.3/2 THEN m ELSE IF A.I 62/37 AND A.3/3 THEN i ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 

IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 

IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 

IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/43 OR (A.162/41 AND A.3/2) THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent 

entity within trust network for access network information that can route outside the trust network, the P- 

Access-Network-lnfo header extension (with or without P-CSCF). 

IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 

the SIP session timer, 
the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism, 
the Session Inititation Protocol (SIP) "Replaces" header. 

the Session Inititation Protocol (SIP) "Replaces" header. 

the Session Inititation Protocol (SIP) "Join" header, 
the Session Inititation Protocol (SIP) "Join" header. 

- an extension to the session initiation protocol for request history 



IF A.162/52 THEN m ELSE n/a - 
IF A.I 62/53 THEN i ELSE n/a - • 
IF A.I 62/53 THEN m ELSE n/a - ■ 
IF A.162/54 THEN m ELSE n/a - • 
IF A.I 62/54 THEN i ELSE n/a - 
IF A.162/55 THEN m ELSE n/a - • 
IF A.I 62/55 THEN i ELSE n/a - ■ 
IF A.162/57 THEN m ELSE n/a ■ 



information. 

IF A.162/60 THEN m ELSE n/a - - the P-User-Database private header extension. 
IF A.162/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 
Profile-Key header. 

IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


NOTE: 


c1 refers to the UA role major capability as th 
SUBSCRIBE and NOTIFY. 


is is the case 


> of a proxy that also acts as a UA specifically for 



Prerequisite A. 163/8 - - INVITE request 

Table A.205: Supported message bodies within the INVITE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.206: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Gseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


c1 


c1 


[26)20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.I 62/9 AND A.162/5) OR A.I 62/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
c2: IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/9 - - INVITE response for all remaining status-codes 

Table A.207: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


1 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




c3 


3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




c3 


4 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 




c3 


5 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


c3 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


8A 


Expires 


[26)20.19 


m 


m 


[26)20.19 


i 


i 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c17 


c17 


[66] 4.1 


c17 


c17 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


11 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c2 


c2 


11A 


P-Access-Network-lnfo 


[52] 4.4 


c14 


c14 


[52] 4.4 


c15 


c15 


11B 


P-Asserted-ldentity 


[34] 9.1 


c6 


c6 


[34) 9.1 


c7 


c7 


lie 


P-Charging-Function- 
Addresses 


[52) 4.5 


c12 


c12 


[52) 4.5 


c13 


c13 


11D 


P-Charging-Vector 


[52] 4.6 


c10 


c10 


[52] 4.6 


c11 


c11 


11E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c5 


n/a 


11F 


Privacy 


[33] 4.2 


c8 


c8 


[33) 4.2 


c9 


c9 


11G 


Reply-To 


[26) 20.31 


m 


m 


[26) 20.31 


i 


i 


11H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


CIS 


c16 


111 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


1 


12 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


13 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


1 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 
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c1: 
c2: 
c3: 
c4: 
c5: 
c6: 

c7: 



c8: 
c9: 

clO: 
c11: 



c12: 
c13: 



c14: 



c15: 



c16: 



c17: 



IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

IF A.162/30A or A.162/30B THEN m ELSE I - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 

IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 

IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 

IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/11 OR A.162/13THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 

IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 



Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A. 164/101 - - Additional for Ixx response 



Table A.208: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


4 


Contact 


[26120.10 


m 


m 


[26] 20.10 


i 


i 


6 


P-Media-Authorization 


[31] 5.1 


c9 


clO 


[31] 5.1 


n/a 


n/a 


9 


Rseq 


[27] 7.1 


m 


m 


[27] 7.1 


i 


i 


11 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c9: IF A.162/26 THEN m ELSE n/a - - SIP extensions for media authorization. 
clO: IF A.3/2 THEN m ELSE n/a - - P-CSCF. 
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Table A.209: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






IB 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


4 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


6 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


8 


P-Media-Authorization 


[31] 5.1 


c9 


clO 


[31] 5.1 


n/a 


n/a 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


10 


Session-Expires 


[58] 4 


c11 


c11 


[58] 4 


c11 


c11 


13 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.162/14THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 
c9: IF A.162/26 THEN m ELSE n/a - - SIP extensions for media authorization. 
clO: IF A.3/2 THEN m ELSE n/a - - P-CSCF. 
c11: IF A. 162/52 THEN m ELSE n/a -- the SIP session timer. 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.209A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.210: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


cl 


cl 


cl: 


IFA.162/19ETHENm 


ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.21 1 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


15 


www-Authenticate 


[26] 20.44 







[26] 20.44 
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Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/50 OR A.164/51 - - Additional for 404 (Not 
Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal Server Error), 
600 (Busy Everywhere), 603 (Decline) response 

Table A.212: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 


12 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



Table A.21 3: Void 

Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.21 4: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


11 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.21 5: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Table A.21 6: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


10 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite: A.164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.216A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Prerequisite A. 16/9 - - INVITE response 

Prerequisite: A.164/28A - - Additional for 422 (Session Interval Too Small) response 

Table A.216B: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Min-SE 


[58] 5 


c1 


c1 


[58] 5 


c1 


c1 


c1: 


IF A.1 62/52 THEN m ELSE n/a - - the SIP session timer. 











Table A.21 7: Void 

Table A.217A: Void 

Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A. 164/45 - - 503 (Service Unavailable) 

Table A.217B: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


1 



Prerequisite A. 163/9 - - INVITE response 

Table A.21 8: Supported message bodies within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.7A MESSAGE method 

Prerequisite A.163/9A - - MESSAGE request 



Table A.218A: Supported headers within the MESSAGE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept-Contact 


[56B] 9.2 


c28 


c28 


[56B] 9.2 


c28 


c29 


1A 


Allow 


[26] 20.5 


m 


m 


[50] 10 


i 


1 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


6 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




i 


7 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




1 


8 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 




i 


9 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


10 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


i 


11 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


12 


Date 


[26)20.17 


m 


m 


[26)20.17 


c2 


c2 


13 


Expires 


[26)20.19 


m 


m 


[26)20.19 


1 


i 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


14A 


History-Info 


[66] 4.1 


c32 


c32 


[66] 4.1 


c32 


c32 


15 


In-Reply-To 


[26] 20.21 


m 


m 


[50) 10 


i 


i 


16 


Max-Forwards 


[26] 20.22 


m 


m 


[26) 20.22 


m 


m 


17 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


18 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c3 


c3 


18A 


P-Access-Network-lnfo 


[52] 4.4 


c23 


c23 


[52] 4.4 


c24 


c24 


18B 


P-Asserted-ldentity 


[34] 9.1 


c10 


c10 


[34] 9.1 


c11 


c11 


18C 


P-Called-Party-ID 


[52] 4.2 


c14 


c14 


[52] 4.2 


c15 


c16 


18D 


P-Charging-Function- 
Addresses 


[52) 4.5 


c21 


c21 


[52) 4.5 


c22 


c22 


18E 


P-Charging-Vector 


[52] 4.6 


c19 


c19 


[52] 4.6 


c20 


c20 


18F 


P-Preferred-ldentity 


[34] 9.2 


x 


X 


[34] 9.2 


c9 


c9 


18G 


P-Profile-Key 


[97)5 


c34 


c34 


[97)5 


c35 


c35 


18H 


P-User-Database 


[82)4 


c33 


c33 


[82)4 


c33 


c33 


181 


P-Visited-Network-ID 


[52] 4.3 


c17 


n/a 


[52] 4.3 


c18 


n/a 


19 


Priority 


[26] 20.26 


m 


m 


[26] 20.26 


i 


i 


19A 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c13 


c13 


20 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c8 


c8 


21 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


21A 


Reason 


[34A) 2 


c26 


c26 


[34A) 2 


c27 


c27 


22 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


22A 


Referred-By 


[59)3 


c30 


c30 


[59)3 


c31 


c31 


23 


Reject-Contact 


[56B] 9.2 


c28 


c28 


[56B] 9.2 


c28 


c29 


23A 


Reply-To 


[26] 20.31 


m 


m 


[26) 20.31 


i 


i 


23B 


Request-Disposition 


[56B] 9.1 


c28 


c28 


[56B] 9.1 


c28 


c28 


24 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


25A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


25B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


26 


Subject 


[26] 20.36 


m 


m 


[26) 20.36 


i 




27 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


28 


Timestamp 


[26) 20.38 


m 


m 


[26) 20.38 


i 




29 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


30 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 




31 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 
c8: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c9: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c10: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c11: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c12: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c13: IF A.162/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c14: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c16: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN i ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c17: IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c18: IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 
c19: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c20: IF A.I 62/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c21 : IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c22: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c23: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c24; IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c25: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c26: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c28: IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c29: IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c30: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c31 : IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c32: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
c33: IF A.162/60 THEN m ELSE n/a - - the P-User-Database private header extension. 

c34: IF A.162/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 

Profile-Key header. 
c35: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Prerequisite A.163/9A - - MESSAGE request 

Table A.218B: Supported message bodies within the IVIESSAGE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 

Table A.218BA: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


c1 


c1 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
g2: if A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/9B - - MESSAGE response for all status-codes 

Table A.218C: Supported headers within the IVIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c3 


c3 


3 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 






4 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 






5 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 






6 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


7 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


i 


8 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


9 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


9A 


Expires 


[26)20.19 


m 


m 


[26)20.19 


i 


i 


10 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10A 


History-Info 


[66] 4.1 


c16 


c16 


[66] 4.1 


c16 


c16 


11 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


1 


12 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c2 


c2 


12A 


P-Access-Network-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


12B 


P-Asserted-ldentity 


[34] 9.1 


c5 


c5 


[34) 9.1 


c8 


c6 


12C 


P-Charging-Function- 
Addresses 


[52) 4.5 


c11 


c11 


[52) 4.5 


c12 


c12 


12D 


P-Charging-Vector 


[52] 4.6 


c9 


n/a 


[52] 4.6 


c10 


n/a 


12E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c4 


n/a 


12F 


Privacy 


[33] 4.2 


c7 


c7 


[33) 4.2 


c8 


c8 


12G 


Reply-To 


[26) 20.31 


m 


m 


[26) 20.31 


i 


i 


12H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c15 


c15 


13 


Server 


[26] 20.35 


m 


m 


[26) 20.35 


i 


1 


14 


Timestamp 


[26] 20.38 


i 


i 


[26) 20.38 


i 


i 


15 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


16 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


1 


17 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


18 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 
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c1: 
c2: 
c3: 
c4: 
c5: 

c6: 



c7: 
c8: 

c9: 
clO: 



c11: 
c12: 



c13: 



c14: 



c15: 



c16: 



IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

IF A.162/30AorA.162/30BTHEN m ELSE I -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 

IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 

IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 

IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/11 OR A.I 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 

IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 



Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.218D: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


Cl 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


4 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 
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Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.218DA: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.218E: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Contact 


[26] 20.10 


m 


m 


[26)20.10 


Cl 


Cl 


c1: IF A.162/19ETHEN m ELSE i- -deleting Contact headers. 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.218F: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.218G: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



Table A.218H: Void 

Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.218I: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) 

Table A.218J: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.218K: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A.164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.218L: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Table A.218M: Void 

Prerequisite A.163/9B - - MESSAGE response 

Table A.218N: Supported message bodies within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.8 NOTIFY method 

Prerequisite A. 163/10 - - NOTIFY request 



Table A.219: Supported headers within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


1A 


Accept-Contact 


[56B] 9.2 


c21 


c21 


[56B] 9.2 


c22 


c22 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 






8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 






9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15A 


History-Info 


[66] 4.1 


c25 


c25 


[66] 4.1 


c25 


c25 


16 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


17 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


17A 


P-Access-Network-lnfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


17B 


P-Asserted-ldentity 


[34] 9.1 


c8 


c8 


[34] 9.1 


c9 


c9 


17C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


17D 


P-Charging-Vector 


[52] 4.6 


c12 


n/a 


[52] 4.6 


c13 


n/a 


17E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


17F 


Privacy 


[33] 4.2 


c10 


clO 


[33] 4.2 


c11 


c11 


18 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


19 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


19A 


Reason 


[34A] 2 


c19 


c19 


[34A] 2 


c20 


c20 


20 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


20A 


Referred-By 


[59] 3 


c23 


c23 


[59] 3 


c24 


c24 


20B 


Reject-Contact 


[56B] 9.2 


c21 


c21 


[56B] 9.2 


c22 


c22 


20C 


Request-Disposition 


[56B] 9.1 


c21 


c21 


[56B] 9.1 


c22 


c22 


21 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


22A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


22B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


23 


Subscription-State 


[28] 8.2.3 


m 


m 


[28] 8.2.3 


i 


i 


24 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


25 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


29 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


1 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/1 4 THEN (IF A.I 62/22 OR A.I 62/27 THEN m ELSE o) ELSE i - - the requirement to be able to 

insert itself in the subsequent transactions in a dialog or (the REFER method or SIP specific event 

notification). 
c8: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c9: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
clO: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c11: IF A.162/31 D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c12: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c14: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c15; IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c16: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c17: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c18: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c19: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c20: IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c21 : IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c22: IF A. 162/50 THEN i ELSE n/a - - caller preferences for the session initiation protocol. 

c23: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c24: IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c25: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/10 - - NOTIFY request 

Table A.220: Supported message bodies within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


sipfrag 


[37] 2 


m 


m 


[37] 2 


i 


i 
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Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.220A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


cl 


[26)20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
c2: IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/11 - - NOTIFY response for all status-codes 



Table A.221 : Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




i 


3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




i 


4 


Content-Language 


[26120.13 


m 


m 


[26)20.13 




i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26)20.15 


i 


i 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c11 


c11 


[52] 4.4 


c12 


c12 


10B 


P-Asserted-ldentity 


[34] 9.1 


c3 


c3 


[34) 9.1 


c4 


c4 


10C 


P-Charging-Function- 
Addresses 


[52) 4.5 


c9 


c9 


[52) 4.5 


clO 


ClO 


10D 


P-Charging-Vector 


[52] 4.6 


c7 


n/a 


[52] 4.6 


c8 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c2 


n/a 


10F 


Privacy 


[33] 4.2 


c5 


c5 


[33) 4.2 


c6 


c6 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c13 


c13 


10H 


Server 


[26] 20.35 


m 


m 


[26) 20.35 


i 


1 


11 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c3: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c4: IF A.162/30AorA.162/30BTHEN m ELSE 1 -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c5: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c6: IF A.162/31 D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c7: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c8: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c9: IF A.162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
clO: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c1 1 : IF A.I 62/43 THEN x ELSE IF A.1 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c12: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access- Network- Info header 

extension. 
c13: IF A.162/11 OR A.1 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 



Prerequisite A. 163/1 1 - - NOTIFY response 
Prerequisite: A. 164/102 - - Additional for 2xx response 

Table A.222: Supported headers within the NOTIFY response 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


c1 


1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


1 


1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


1 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3; IF A.162/15 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.222A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/1 1 - - NOTIFY response 
Prerequisite: A. 164/103 - - Additional for 3xx response 

Table A.223: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Contact 


[26120.10 


m 


m 


[26)20.10 


c1 


c1 


c1: 


IFA.162/19ETHENm ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.224: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.225: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 
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Table A.226: Void 

Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.227: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.228: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.229: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.229A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
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Table A.230: Void 

Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/35 - - Additional for 485 (Ambigious) response 

Table A.230A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 



Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/39 - - Additional for 489 (Bad Event) response 



Table A.231 : Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


c1 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 


NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/1 1 - - NOTIFY response 

Table A.232: Supported message bodies within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.9 OPTIONS method 

Prerequisite A. 163/12 - - OPTIONS request 



Table A.233: Supported headers within the OPTIONS request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


1A 


Accept-Contact 


[56B] 9.2 


c28 


c28 


[56B] 9.2 


c28 


c29 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


1 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


8 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






9 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 






10 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 






11 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16A 


History-Info 


[66] 4.1 


c32 


c32 


[66] 4.1 


c32 


c32 


17 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


18 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


19 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


19A 


P-Access-Network-lnfo 


[52] 4.4 


c23 


c23 


[52] 4.4 


c24 


c24 


19B 


P-Asserted-ldentity 


[34] 9.1 


c10 


c10 


[34] 9.1 


c11 


c11 


19C 


P-Called-Party-ID 


[52] 4.2 


c14 


c14 


[52] 4.2 


c15 


c16 


19D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c21 


c21 


[52] 4.5 


c22 


c22 


19E 


P-Charging-Vector 


[52] 4.6 


c19 


c19 


[52] 4.6 


c20 


c20 


19F 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c9 


c9 


19G 


P-Profile-Key 


[9715 


c34 


c34 


[9715 


c35 


c35 


19H 


P-User-Database 


[82] 4 


c33 


c33 


[8214 


c33 


c33 


191 


P-Visited-Network-ID 


[52] 4.3 


c17 


n/a 


[52] 4.3 


c18 


n/a 


19J 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c13 


c13 


20 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c8 


c8 


21 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


21A 


Reason 


[34A] 2 


c26 


c26 


[34A] 2 


c27 


c27 


22 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


22A 


Referred-By 


[59] 3 


c30 


c30 


[59] 3 


c31 


c31 


22B 


Reject-Contact 


[56B1 9.2 


c28 


c28 


[56B1 9.2 


c28 


c29 


22C 


Request-Disposition 


[56B] 9.1 


c28 


c28 


[56B] 9.1 


c28 


c28 


23 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


24A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


24B 


Security-Verify 


[48] 2.3.1 


X 


X 


[481 2.3.1 


c25 


c25 


25 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


26 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 
c8: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c9: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

clO: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks, 
oil: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c12: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c13: IF A.162/31 D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c14: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c16: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN i ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c17: IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c18: IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 
c19: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c20: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c21 : IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c22: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c23: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c24; IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c25: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c26: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c28: IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c29: IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c30: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c31 : IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c32: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
c33: IF A.162/60 THEN m ELSE n/a - - the P-User-Database private header extension. 

c34: IF A.162/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 

Profile-Key header. 
c35: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Prerequisite A. 163/12 - - OPTIONS request 

Table A.234: Supported message bodies within the OPTIONS request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Table A.235: Void 

Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 

Table A.235A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[28] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
g2: if A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/13 - - OPTIONS response for all status-codes 



Table A.236: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c3 


c3 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 






3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 






4 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 






5 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


i 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c16 


c16 


[66] 4.1 


c16 


c16 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


11 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c2 


c2 


11A 


P-Access-Network-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


11B 


P-Asserted-ldentity 


[34] 9.1 


c5 


c5 


[34) 9.1 


c6 


c6 


11C 


P-Charging-Function- 
Addresses 


[52) 4.5 


c11 


c11 


[52) 4.5 


c12 


c12 


11D 


P-Charging-Vector 


[52] 4.6 


c9 


c9 


[52] 4.6 


clO 


ClO 


11E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c4 


n/a 


11F 


Privacy 


[33] 4.2 


c7 


c7 


[33) 4.2 


c8 


c8 


11G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c15 


c15 


11H 


Server 


[26] 20.35 


m 


m 


[26) 20.35 


i 


i 


12 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


13 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3: IF A.162/19COR A.162/19DTHEN m ELSE 1 -- reading, adding or concatenating the Call-Info header. 

c4: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c5: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c6: IF A.162/30AorA.162/30BTHEN m ELSE 1 -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c7: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c8: IF A.162/31 D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c9: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c11: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c12: IF A.162/44A THEN m ELSE IF A.162/44 THEN 1 ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c13: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c15: IF A.162/11 OR A.I 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c16: IF A.162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
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Table A.237: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






IB 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


12 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.237A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.238: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


cl 


c1 


cl: 


IFA.162/19ETHENm 


ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.239: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.240: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Retry-After 


[26] 20.33 


m 


m 


[28] 20.33 


i 


i 



Table A.241 : Void 

Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.242: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.243: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[261 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/1 3 - - OPTIONS response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.244: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A.164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.244A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Table A.245: Void 

Prerequisite A. 163/13 - - OPTIONS response 

Table A.246: Supported message bodies within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.10 PRACK method 

Prerequisite A. 163/14 - - PRACK request 



Table A.247: Supported headers within the PRACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


1A 


Accept-Contact 


[56B] 9.2 


c18 


c18 


[56B] 9.2 


c19 


c19 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


1 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 




c3 


8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 




c3 


9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 




c3 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


16 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c14 


c14 


[52] 4.4 


c15 


c15 


16B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c12 


c12 


[52] 4.5 


c13 


c13 


16C 


P-Charging-Vector 


[52] 4.6 


c10 


n/a 


[52] 4.6 


c11 


n/a 


16D 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c9 


c9 


17 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


18 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


19 


Rack 


[27] 7.2 


m 


m 


[27] 7.2 


i 


i 


19A 


Reason 


[34A] 2 


c16 


c16 


[34A] 2 


c17 


c17 


20 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


20A 


Referred-By 


[59] 3 


c20 


c20 


[59] 3 


c21 


c21 


20B 


Reject-Contact 


[56B] 9.2 


c18 


c18 


[56B] 9.2 


c19 


c19 


20C 


Request-Disposition 


[56B] 9.1 


c18 


c18 


[56B] 9.1 


c19 


c19 


21 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


23 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


24 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


25 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


26 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


27 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3: 
c4: 
c5: 



c6: 

c7: 

c8: 
c9: 

clO: 
c11: 



c12: 
c13: 



c14: 



c15; 



c16 
c17 
c18 
c19 
c20 
c21 



IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 

IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

IF A.162/14 THEN ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 

IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 

IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

- the Reason header field for the session initiation protocol, 
the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol, 
caller preferences for the session initiation protocol, 
the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 



IF A.162/48 THEN m ELSE n/a ■ 
IF A.162/48 THEN i ELSE n/a - ■ 
IF A.162/50 THEN m ELSE n/a ■ 
IF A.162/50 THEN i ELSE n/a - ■ 
IF A.I 62/53 THEN i ELSE n/a - ■ 
IF A.I 62/53 THEN m ELSE n/a ■ 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/14 - - PRACK request 

Table A.248: Supported message bodies within the PRACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Table A.249: Void 

Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 

Table A.249A: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
g2: if A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/15 - - PRACK response for all status-codes 



Table A.250: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




c2 


3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




c2 


4 


Content-Language 


[26120.13 


m 


m 


[26)20.13 




c2 


5 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26)20.15 


i 


c2 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c2 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c9 


c9 


[52] 4.4 


clO 


ClO 


10B 


P-Charging-Function- 
Addresses 


[52) 4.5 


c7 


c7 


[52) 4.5 


c8 


c8 


10C 


P-Charging-Vector 


[52] 4.6 


c5 


n/a 


[52] 4.6 


c6 


n/a 


10D 


Privacy 


[33] 4.2 


c3 


c3 


[33) 4.2 


c4 


c4 


10E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c11 


c11 


10F 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c3: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c4: IF A.162/31 D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c5: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c6: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c7: IF A.162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c8: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c9: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
clO: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a -- act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c11: IF A.162/11 OR A.1 62/1 3 THEN m ELSE i-- reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 



Prerequisite A. 163/15 - - PRACK response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.251 : Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


cl 


cl 


OB 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


1 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 
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Supported 



[26] 20.37 I m 



m 



[26] 20.37 I i 



c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/3 - - PRACK response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.251 A: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.252: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Contact 


[26] 20.10 


m 


m 


[26)20.10 


c1 


c1 


c1: 


IFA.162/19ETHENm 


ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.253: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.254: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 
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Table A.255: Void 

Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.256: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.257: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A. 164/27 - - Addition for 420 (Bad Extension) response 



Table A.258: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/15 - - PRACK response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.258A: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
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Table A.259: Void 

Prerequisite A. 163/15 - - PRACK response 

Table A.260: Supported message bodies within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.2.2.4.10A PUBLISH method 

Prerequisite A. 163/1 5 A - - PUBLISH request 



Table A.260A: Supported headers within the PUBLISH request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept-Contact 


[56B1 9.2 


c28 


c28 


[56B1 9.2 


c28 


c29 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


3 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c29 


c29 


4 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


5 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6 


Call-Info 


[26] 24.9 


m 


m 


[26] 24.9 


c4 


c4 


7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 






8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 






9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


Event 


[70] 4, 6 


m 


m 


[70] 4, 6 


m 


m 


15 


Expires 


[26] 
20.19, 
[70] 4, 5, 
6 


m 


m 


[26] 
20.19, 
[70] 4, 5, 
6 


i 


i 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16A 


History-Info 


[66] 4.1 


c32 


c32 


[66] 4.1 


c32 


c32 


17 


In-Reply-To 


[26] 20.21 


m 


m 


[26] 20.21 


i 


i 


18 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


19 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


20 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


21 


P-Access-Network-lnfo 


[52] 4.4 


c23 


c23 


[52] 4.4 


c24 


c24 


22 


P-Asserted-ldentity 


[34] 9.1 


clO 


clO 


[34] 9.1 


c11 


Gil 


23 


P-Called-Party-ID 


[52] 4.2 


c14 


c14 


[52] 4.2 


c15 


c16 


24 


P-Charging-Function- 
Addresses 


[52] 4.5 


c21 


021 


[52] 4.5 


c22 


c22 


25 


P-Charging-Vector 


[52] 4.6 


c19 


c19 


[52] 4.6 


c20 


c20 


26 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c9 


c9 
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26A 


P-Profile-Key 


[97] 5 


c34 


c34 


[97] 5 


c35 


c35 


26B 


P-User-Database 


[82] 4 


c33 


c33 


[82] 4 


c33 


c33 


27 


P-Visited-Network-ID 


[52] 4.3 


c17 


n/a 


[52] 4.3 


c18 


n/a 


28 


Priorita 


[26] 20.26 


m 


m 


[26] 20.26 


i 


1 


29 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c13 


c13 


30 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c7 


c7 


31 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


32 


Reason 


[34A] 2 


c8 


c8 


[34A] 2 


Cl 


cl 


33 


Referred-By 


[59] 3 


c30 


c30 


[59] 3 


c31 


c31 


34 


Reject-Contact 


[568] 9.2 


c27 


c27 


[56B] 9.2 


c27 


c28 


34A 


Reply-To 


[26] 20.31 


m 


m 


[26] 20.31 


i 


1 


35 


Request-Disposition 


[56B] 9.1 


c27 


c27 


[568] 9.1 


c27 


c27 


36 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


37 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


38 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


39 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c26 


c26 


40 


SIP-lf-Match 


[70] 
11.3.2 


m 


m 


[70] 
11.3.2 






41 


Subject 


[26] 20.36 


m 


m 


[26] 20.36 






42 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


43 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 






44 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


45 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 






46 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

g3: if A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c8: IF A.162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c9: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c10: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c11: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c12: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c13: IF A.162/31 D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c14: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c16: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN i ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c17: IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c18: IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 
c19: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c20: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c21 : IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c22; IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c23: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c24: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c25: IF A. 162/47 THEN o ELSE n/a- - security mechanism agreement for the session initiation protocol (note 1). 

c26: IF A. 162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c27: IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c28: IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c29: IF A.4/20 THEN m ELSE i - - SIP specific event notification extension (note 2). 

c30: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c31 : IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c32: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
c33: IF A.162/60 THEN m ELSE n/a - - the P-User-Database private header extension. 

c34: IF A.162/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 

Profile-Key header. 
c35: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 



NOTE 1 : Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. 
NOTE 2: c29 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 

SUBSCRIBE and NOTIFY. 
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Prerequisite A.163/15A - - PUBLISH request 

Table A.260B: Supported message bodies within the PUBLISH request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.260BA: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
c2: IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



297 



ETSI TS 124 229 V7.6.0 (2006-12) 



Prerequisite A. 163/15B - - PUBLISH response for all status-codes 

Table A.260C: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Call-Info 


[26] 24.9 


m 


m 


[26] 24.9 


c3 


c3 


3 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 






4 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 






5 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 






6 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


7 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


i 


8 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


9 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


10 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10A 


History-Info 


[66] 4.1 


c16 


c16 


[66] 4.1 


c16 


c16 


11 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


12 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c2 


c2 


13 


P-Access-Network-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


14 


P-Asserted-ldentity 


[34] 9.1 


c5 


c5 


[34) 9.1 


c6 


c6 


15 


P-Charging-Function- 
Addresses 


[52) 4.5 


c11 


c11 


[52) 4.5 


c12 


c12 


16 


P-Charging-Vector 


[52] 4.6 


c9 


n/a 


[52] 4.6 


c10 


n/a 


17 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c4 


n/a 


18 


Privacy 


[33] 4.2 


c7 


c7 


[33) 4.2 


c8 


c8 


19 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c15 


c15 


20 


Server 


[26] 20.35 


m 


m 


[26) 20.35 


i 


i 


21 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


22 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


23 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


24 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


25 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3: IF A.162/19COR A.162/19DTHEN m ELSE 1 -- reading, adding or concatenating the Call-Info header. 

c4: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c5: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c6: IF A.162/30AorA.162/30BTHEN m ELSE 1 -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c7: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c8: IF A.162/31 D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c9: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c11: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c12: IF A.162/44A THEN m ELSE IF A.162/44 THEN 1 ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c13: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c15: IF A.162/11 OR A.1 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c16: IF A.162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
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Prerequisite A.163/15B - - PUBLISH response 
Prerequisite: A. 164/7 - - Additional for 200 (OK) response 

Table A.260D: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


3 


Expires 


[26] 
20.19, 
[70] 4, 5, 
6 


m 


m 


[26] 
20.19, 
[70] 4, 5, 
6 


i 


1 


4 


SIP-Etag 


[70] 
11.3.1 


m 


m 


[70] 
11.3.1 


i 


i 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.260DA: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.260E: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


Cl 


c1: 


IFA.162/19ETHENm 


ELSE i - 


- deleting Contact headers. 









Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A. 164/11 OR A. 164/12 - - Additional for 401 (Unauthorized) 
response 

Table A.260F: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.260G: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[28] 20.33 


i 


i 



Table A.260H: Void 

Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.260I: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.260J: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[261 20.3 


m 


m 


[26] 20.3 







Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.260K: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite: A.164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.260L: Supported headers within the PUBLISIH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


Cl 


[48] 2 


n/a 


n/a 


c1: IF A.162/47THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/29 - - Additional for 423 (Interval Too Brief) response 

Table A.260l\/I: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


Min-Expires 


[26] 
20.23, 
[70] 5, 6 


m 


m 


[26] 
20.23, 
[70] 5, 6 


i 


1 



Prerequisite A.163/15B - - PUBLISH response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.260N: Void 

Prerequisite A.163/15B - - PUBLISH response 

Prerequisite: A. 164/39 - - Additional for 489 (Bad Event) response 

Table A.260O: Supported headers within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Allow-Events 


[28] 8.2.2 


m 


m 


[28] 8.2.2 


i 


1 



Prerequisite A. 163/17 - - PUBLISH response 

Table A.260P: Supported message bodies within the PUBLISH response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



301 



ETSI TS 124 229 V7.6.0 (2006-12) 



A.2.2.4.11 REFER method 

Prerequisite A. 163/16 - - REFER request 



Table A.261 : Supported headers within the REFER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


OB 


Accept-Contact 


[56B] 9.2 


c27 


c27 


[56B] 9.2 


c27 


c28 


OC 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






1 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






1A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






5A 


Content-Disposition 


[26] 20.11 


m 


m 


[26120.11 






5B 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 






5C 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






6 


Content-Length 


[26] 20.14 


m 


m 


[26120.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


8 


Cseq 


[26] 20.16 


m 


m 


[26120.16 


m 


m 


9 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


10 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


11A 


History-Info 


[66] 4.1 


c31 


c31 


[66] 4.1 


c31 


c31 


12 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


13 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


14 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


14A 


P-Access-Network-lnfo 


[52] 4.4 


c22 


c22 


[52] 4.4 


c23 


c23 


14B 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[341 9.1 


c10 


clO 


14C 


P-Called-Party-ID 


[52] 4.2 


c13 


c13 


[52] 4.2 


c14 


c15 


14D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c20 


[52] 4.5 


c21 


c21 


14E 


P-Charging-Vector 


[52] 4.6 


c18 


c18 


[52] 4.6 


c19 


c19 


14F 


P-Preferred-ldentity 


[34] 9.2 


x 


X 


[34] 9.2 


c8 


c8 


14G 


P-Profile-Key 


[9715 


c33 


c33 


[9715 


c34 


c34 


14H 


P-User-Database 


[82] 4 


c32 


c32 


[8214 


c32 


c32 


141 


P-Visited-Network-ID 


[52] 4.3 


c16 


n/a 


[52] 4.3 


c17 


n/a 


14J 


Privacy 


[33] 4.2 


oil 


oil 


[33] 4.2 


c12 


c12 


15 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


16 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


16A 


Reason 


[34A] 2 


c25 


c25 


[34A] 2 


c26 


c26 


17 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


18 


Refer-To 


[36] 3 


c3 


c3 


[36] 3 


c4 


c4 


18A 


Referred-By 


[5913 


c29 


c29 


[5913 


c30 


c30 


18B 


Reject-Contact 


[56B] 9.2 


c27 


c27 


[56B1 9.2 


c27 


c28 


18C 


Request-Disposition 


[56B] 9.1 


c27 


c27 


[56B] 9.1 


c27 


c27 


19 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


20 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


20A 


Security-Client 


[481 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


20B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


21 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


22 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


23 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


24 


User-Agent 


[261 20.41 


m 


m 


[26] 20.41 


i 


i 


25 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/14 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 
c8: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c9: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
clO: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network, 
oil: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c12: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 

c14: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN i ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c16: IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c17: IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 
c18: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c19: IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c20: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c21 ; IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c22: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c23: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c24: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c25: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c26: IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c28: IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c29: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c30: IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c31 : IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
c32: IF A.162/60 THEN m ELSE n/a - - the P-User-Database private header extension. 

c33: IF A.162/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 

Profile-Key header. 
c34: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/16 - - REFER request 

Table A.262: Supported message bodies within the REFER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Table A.263: Void 

Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 

Table A.263A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
g2: if A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/17 - - REFER response for all status-codes 



Table A.264: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


1 


i 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Contact 


[26] 20.10 


m 


m 


[26)20.10 






1B 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 






2 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 






3 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 






4 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


5 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


1 


i 


6 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


7 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


8 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


8A 


History-Info 


[66] 4.1 


c15 


c15 


[66] 4.1 


c15 


c15 


9 


IVIIME-Version 


[26] 20.24 


m 


m 


[26) 20.24 


1 


i 


10 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c2 


c2 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


10B 


P-Asserted-ldentity 


[34] 9.1 


c4 


c4 


[34) 9.1 


c5 


c5 


10C 


P-Charging-Function- 
Addresses 


[52) 4.5 


clO 


ClO 


[52) 4.5 


c11 


c11 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


c8 


[52] 4.6 


c9 


c9 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10F 


Privacy 


[33] 4.2 


c6 


c6 


[33) 4.2 


c7 


c7 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


10H 


Server 


[26] 20.35 


m 


m 


[26) 20.35 


1 


i 


11 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


1 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


1 


i 


c1: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A. 162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c5: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c6: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c7: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
clO: IF A.162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c11: IFA.162/44ATHEN m ELSE IF A.162/44 THEN i ELSE n/a -- adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c12: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c13: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c14: IF A.162/11 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c15: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
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Prerequisite A. 163/17 - - REFER response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.265: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


c1 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


5 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.162/15 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.265A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Table A.266: Void 



Prerequisite A. 163/17 - - REFER response 



Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A. 164/11 OR A. 164/12 - - Additional for 401 (Unauthorized) 
response 

Table A.267: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.268: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


6 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 
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Table A.269: Void 

Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.270: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 







[26] 20.27 







8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.271 : Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Table A.272: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.272A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
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Table A.273: Void 

Prerequisite A. 163/17 - - REFER response 

Table A.274: Supported message bodies within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



308 



ETSI TS 124 229 V7.6.0 (2006-12) 



A.2.2.4.12 REGISTER method 

Prerequisite A. 163/1 8 - - REGISTER request 



Table A.275: Supported headers within the REGISTER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 




1 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 




i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 




i 


3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 




i 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7, 
[49] 


m 


m 


[26] 20.7, 
[49] 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c2 


c2 


8 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 




i 


9 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 




i 


10 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 




i 


11 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 




i 


12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


m 


m 


16 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


1 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17A 


History-Info 


[66] 4.1 


c24 


c24 


[66] 4,1 


c24 


c24 


18 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


19 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


20 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


20A 


P-Access-Network-lnfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


20C 


P-Charging-Vector 


[52] 4.6 


c12 


c12 


[52] 4.6 


c13 


c13 


20D 


P-User-Database 


[82] 4 


c25 


c25 


[82] 4 


n/a 


n/a 


20E 


P-Visited-Network-ID 


[52] 4.3 


c10 


c10 


[52] 4.3 


c11 


c11 


20F 


Path 


[35] 4.2 


c6 


c6 


[35] 4.2 


c6 


c6 


20G 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c9 


c9 


21 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c7 


c7 


22 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


22A 


Reason 


[34A] 2 


c19 


c19 


[34A] 2 


c20 


c20 


22B 


Referred-By 


[59] 3 


c22 


c22 


[59] 3 


c23 


c23 


22C 


Request-Disposition 


[56B] 9.1 


c21 


c21 


[56B] 9.1 


c21 


c21 


23 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c4 


c4 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


24A 


Security-Client 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c18 


c18 


24B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


25 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c5 


c5 


26 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c3: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/1 1 OR A.162/12 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c5: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c6: IF A.162/29 THEN m ELSE n/a - - PATH header support. 

c7: IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

c8: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c9: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
clO: IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension, 

oil: IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 
c12: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c14: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c15: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c16: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c17: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a -- act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c18: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c19: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c20: IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c21 : IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c22: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c23: IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c24: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
c25: IF A.162/60 THEN m ELSE n/a - - the P-User-Database private header extension. 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/18 - - REGISTER request 

Table A.276: Supported message bodies within the REGISTER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Table A.277: Void 

Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 

Table A.277A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[261 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
g2: if A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/19 - - REGISTER response for all status-codes 

Table A.278: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c2 


c2 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




i 


3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




i 


4 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 




i 


5 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


i 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26120.17 


m 


m 


[26)20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c12 


c12 


[66] 4.1 


c12 


c12 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


11 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c1 


Cl 


11A 


P-Access-Network-lnfo 


[52] 4.4 


c9 


c9 


[52] 4.4 


clO 


ClO 


11B 


P-Charging-Function- 
Addresses 


[52) 4.5 


c7 


c7 


[52) 4.5 


c8 


c8 


lie 


P-Charging-Vector 


[52] 4.6 


c5 


c5 


[52] 4.6 


c6 


c6 


11D 


Privacy 


[33] 4.2 


c3 


c3 


[33) 4.2 


c4 


c4 


11E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c11 


c11 


11F 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


12 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


13 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1: IF A.162/19AOR A.162/19BTHEN m ELSE i -- reading, adding or concatenating the Organization tieader. 
c2: IF A.162/19COR A.162/19DTHEN m ELSE i -- reading, adding or concatenating the Call-Info header. 
c3: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c4: IF A.162/31D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c5: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c6: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c7: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c8: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c9: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
clO: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c11: IF A.162/11 OR A.1 62/1 2 THEN m ELSE i-- reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c12: IF A.162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 

Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



312 



ETSI TS 124 229 V7.6.0 (2006-12) 



Table A.279: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






1B 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


5A 


P-Associated-URI 


[52] 4.1 


c8 


c8 


[52] 4.1 


c9 


clO 


6 


Path 


[35] 4.2 


c3 


c3 


[35] 4.2 


c4 


c4 


8 


Service-Route 


[38] 5 


c5 


c5 


[38] 5 


c6 


c7 


9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 
c2: IF A.3/2 OR A.3/3A THEN m ELSE n/a - - P-CSCF or l-CSCF (THIG). 
c3: IF A.162/29 THEN m ELSE n/a - - Path extension support. 
c4: IF A.162/29 THEN i ELSE n/a - - Path extension support. 
c5: IF A.162/32 THEN m ELSE n/a - - Service-Route extension support. 
c6: IF A.162/32 THEN i ELSE n/a - - Service-Route extension support. 

c7: IF A.162/32 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - Service-Route extension and P-CSCF. 
c8: IF A.162/36 THEN m ELSE n/a - - the P-Associated-URI extension. 
c9: IF A.162/36 THEN 1 ELSE n/a - - the P-Associated-URI extension. 

clO: IF A.162/36 AND A.3/2 THEN m ELSE IF A.162/36 AND A.3/3 THEN 1 ELSE n/a - - the P-Associated-URI 
extension and P-CSCF or l-CSCF. 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.171A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.280: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


c2 


c2 


c2: 


IFA.162/19ETHENm 


ELSE i - 


- deleting Contact headers. 
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Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.281 : Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


Security-Server 


[48] 2 


X 


Cl 


[48)2 


n/a 


n/a 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 


c1: IF A.162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.282: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


1 



Table A.283: Void 

Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.284: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


9 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.285: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 
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Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.286: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: 


IF A. 162/1 7 THEN m ELSE.i 















Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.286A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


Cl 


[48] 2 


n/a 


n/a 


c1 : IF A.I 62/47 THEN m ELSE n/a - - security mechanism agreement for tine session initiation protocol. 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/29 - - Additional for 423 (Interval Too Brief) response 

Table A.287: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Min-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


i 


1 



Table A.288: Void 

Prerequisite A. 163/19 - - REGISTER response 

Table A.289: Supported message bodies within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.13 SUBSCRIBE method 

Prerequisite A. 163/20 - - SUBSCRIBE request 



Table A.290: Supported headers within the SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


1A 


Accept-Contact 


[56B] 9.2 


c27 


c27 


[56B] 9.2 


c27 


c28 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 






8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 






9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16A 


History-Info 


[66] 4.1 


c31 


c31 


[66] 4.1 


c31 


c31 


17 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


18 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


18A 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


18B 


P-Access-Network-lnfo 


[52] 4.4 


c22 


c22 


[52] 4.4 


c23 


c23 


18C 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[34] 9.1 


clO 


clO 


18D 


P-Called-Party-ID 


[52] 4.2 


c13 


c13 


[52] 4.2 


c14 


c15 


18E 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c20 


[52] 4.5 


c21 


c21 


18F 


P-Charging-Vector 


[52] 4.6 


c18 


c18 


[52] 4.6 


c19 


c19 


18G 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c8 


c8 


18H 


P-Profile-Key 


[97] 5 


c33 


c33 


[97] 5 


c34 


c34 


181 


P-User-Database 


[82] 4 


c32 


c32 


[82] 4 


c32 


c32 


18J 


P-Visited-Network-ID 


[52] 4.3 


c16 


n/a 


[52] 4.3 


c17 


n/a 


18K 


Privacy 


[33] 4.2 


c11 


oil 


[33] 4.2 


c12 


c12 


19 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


20 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


20A 


Reason 


[34A] 2 


c25 


c25 


[34A] 2 


c26 


c26 


21 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


21A 


Referred-By 


[5913 


c29 


c29 


[5913 


c30 


c30 


21B 


Reject-Contact 


[56B] 9.2 


c27 


c27 


[56B] 9.2 


c27 


c28 


21C 


Request-Disposition 


[56B] 9.1 


c27 


c27 


[56B] 9.1 


c27 


c27 


22 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


23 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


23A 


Security-Client 


[48] 2.3.1 


X 


X 


[481 2.3.1 


c24 


c24 


23B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


24 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


25 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 


m 


m 


[261 20.41 


i 


i 


28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 
c7: IF A.162/14 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 
c8: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c9: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c10: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c11: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c12: IF A.162/31D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 

c14: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN i ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c16: IF A.162/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c17: IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 
c18: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c19: IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c20: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c21 ; IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c22: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c23: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c24: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c25: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c26: IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A. 162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c28: IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c29: IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c30: IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c31 : IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 
c32: IF A.162/60 THEN m ELSE n/a - - the P-User-Database private header extension. 

c33: IF A.162/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 

Profile-Key header. 
c34: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/20 - - SUBSCRIBE request 

Table A.291 : Supported message bodies within the SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 

Table A.291 A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


cl 


[26)20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
c2: IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/21 - - SUBSCRIBE response for all status-codes 

Table A.292: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




i 


3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




i 


4 


Content-Language 


[26120.13 


m 


m 


[26)20.13 




i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26)20.15 


i 


i 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c15 


c15 


[66] 4.1 


c15 


c15 


10 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10A 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c2 


c2 


10B 


P-Access-Network-lnfo 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


10C 


P-Asserted-ldentity 


[34] 9.1 


c4 


c4 


[34] 9.1 


c5 


c5 


10D 


P-Charging-Function- 
Addresses 


[52) 4.5 


clO 


ClO 


[52) 4.5 


c11 


c11 


10E 


P-Charging-Vector 


[52] 4.6 


c8 


c8 


[52] 4.6 


c9 


c9 


10F 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10G 


Privacy 


[33] 4.2 


c6 


c6 


[33) 4.2 


c7 


c7 


10H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


101 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

g2: if A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 
c5: IF A.162/30AorA.162/30BTHEN m ELSE 1 -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 

trust network. 
c6: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c7: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
clO: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c12: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c13: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c14: IF A.162/11 OR A.I 62/1 3 THEN m ELSE i-- reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c15: IF A.162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 



Prerequisite A. 163/21 - - SUBSCRIBE response 
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Table A.293: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 






1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 






1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






2 


Expires 


[26)20.19 


m 


m 


[26)20.19 






3 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: IF A.162/15 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.293A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Error-Info 


[26)20.18 


m 


m 


[26)20.18 


i 


i 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.294: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Contact 


[26)20.10 


m 


m 


[26)20.10 


c1 


Cl 


c1: IF A.162/19ETHEN m ELSE i- -deleting Contact headers. 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.295: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26) 20.44 


i 


i 
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Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 

A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily not available), 486 

(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.296: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[28] 20.33 


i 


i 



Table A.297: Void 

Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.298: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.299: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[261 20.3 


m 


m 


[26] 20.3 







Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.300: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite: A.164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.300A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/29 - - Additional for 423 (Interval Too Brief) response 

Table A.301 : Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Min-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


i 


1 



Table A.302: Void 

Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/39 - - Additional for 489 (Bad Event) response 

Table A.303: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


c1 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 


NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Table A.303A: Void 

Prerequisite A.163/21 - - SUBSCRIBE response 

Table A.304: Supported message bodies within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.14 UPDATE method 

Prerequisite A. 163/22 - - UPDATE request 



Table A.305: Supported headers within the UPDATE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


1A 


Accept-Contact 


[56B] 9.2 


c21 


c21 


[56B] 9.2 


c22 


c22 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






4 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






5 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


Cl 


6 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


7 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c8 


c8 


9 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


10 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


c4 


c4 


11 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


c4 


c4 


12 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


c4 


c4 


13 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


14 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


c4 


c4 


15 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


16 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


18 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


19 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c4 


19A 


Min-SE 


[58] 5 


c23 


c23 


[58] 5 


c23 


c23 


20 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


20A 


P-Access-Network-lnfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


20C 


P-Charging-Vector 


[52] 4.6 


c12 


c12 


[52] 4.6 


c13 


c13 


20D 


Privacy 


[33] 4.2 


c10 


clO 


[33] 4.2 


c11 


c11 


21 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c9 


c9 


22 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


22A 


Reason 


[34A] 2 


c19 


c19 


[34A] 2 


c20 


c20 


23 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


23A 


Referred-By 


[59] 3 


c24 


c24 


[59] 3 


c25 


c25 


23B 


Reject-Contact 


[56B] 9.2 


c21 


c21 


[56B] 9.2 


c22 


c22 


23C 


Request-Disposition 


[56B] 9.1 


c21 


c21 


[56B] 9.1 


c22 


c22 


24 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


25A 


Security-Client 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c18 


c18 


25B 


Security-Verify 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c18 


c18 


25C 


Session-Expires 


[5814 


c23 


c23 


[58] 4 


c23 


c23 


26 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


27 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


28 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


29 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


30 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3: 
c4: 
c5: 



c6: 

c7: 

c8: 
c9: 
clO: 
c11: 

c12: 
c13: 



c14: 
c15: 



c16: 



c17: 



c18 
c19 
c20 
c21 
c22 
c23 
c24 
c25 



IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 

IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 

IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 

IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

IF A. 162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

- caller preferences for the session initiation protocol, 
caller preferences for the session initiation protocol. 

- the SIP session timer. 

IF A.I 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

IF A.I 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 



IF A.162/50 THEN m ELSE n/a ■ 
IF A.162/50 THEN i ELSE n/a - ■ 
IF A.162/52 THEN m ELSE n/a ■ 



NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/22 - - UPDATE request 

Table A.306: Supported message bodies within the UPDATE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.306A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26)20.14 


m 


m 


3 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


4 


Date 


[26)20.17 


Cl 


cl 


[26)20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a - - stateful proxy behaviour that inserts date, or 

stateless proxies. 
c2: IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/22 - - UPDATE response for all status-codes 



Table A.307: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26) 20.5 


i 


i 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


1B 


Contact 


[26] 20.10 


m 


m 


[26)20.10 




i 


2 


Content-Disposition 


[26] 20.11 


m 


m 


[26)20.11 




c3 


3 


Content-Encoding 


[26)20.12 


m 


m 


[26)20.12 




c3 


4 


Content-Language 


[26)20.13 


m 


m 


[26)20.13 




c3 


5 


Content-Length 


[26)20.14 


m 


m 


[26)20.14 


m 


m 


6 


Content-Type 


[26)20.15 


m 


m 


[26)20.15 


i 


c3 


7 


Cseq 


[26)20.16 


m 


m 


[26)20.16 


m 


m 


8 


Date 


[26)20.17 


m 


m 


[26)20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


10A 


Organization 


[26) 20.25 


m 


m 


[26) 20.25 


c2 


c2 


10B 


P-Access-Network-lnfo 


[52] 4.4 


c11 


c11 


[52] 4.4 


c12 


c12 


10C 


P-Charging-Function- 
Addresses 


[52) 4.5 


c9 


c9 


[52) 4.5 


c10 


clO 


10D 


P-Charging-Vector 


[52] 4.6 


c7 


n/a 


[52] 4.6 


c8 


n/a 


10E 


Privacy 


[33] 4.2 


c5 


c5 


[33) 4.2 


c6 


c6 


10F 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c13 


c13 


10G 


Server 


[26] 20.35 


m 


m 


[26) 20.35 


i 


i 


11 


Timestamp 


(26) 20.38 


m 


m 


[26) 20.38 


i 


i 


12 


To 


[26) 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26) 20.43 


m 


m 


[26) 20.43 


i 


i 


c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c6: IF A.162/31 D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c7: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c8: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 
c9: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
clO: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 
c1 1 : IF A.I 62/43 THEN x ELSE IF A.I 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c12: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 
c13: IF A.162/11 OR A.I 62/1 3 THEN m ELSE i-- reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 



Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A. 164/102 - - Additional for 2xx response 

Table A.308: Supported headers within the UPDATE response 



Item 



Header 



Sending 



Receiving 
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Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






OB 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






OC 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


3 


Contact 


[26)20.10 


m 


m 


[26)20.10 


i 


i 


4 


Session-Expires 


[58] 4 


c4 


c4 


[58] 4 


c4 


c4 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 

and downstream direction when record routeing. 
c4: IF A.162/52 THEN m ELSE n/a - - the SIP session timer 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/103 OR A. 164/104 OR A. 164/105 OR A. 164/106 - - Additional for 3xx - 6xx response 

Table A.308A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26)20.18 


m 


m 


[26)20.18 


i 


i 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/103 or A. 164/35 - - Additional for 3xx, 485 (Ambiguous) response 

Table A.309: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Contact 


[26)20.10 


m 


m 


[26)20.10 


c1 


cl 


c1: IF A.1 62/1 9ETHEN m ELSE i- -deleting Contact headers. 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.309A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26) 20.44 


i 


i 
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Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A. 164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 

Table A.310: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Retry-After 


[26] 20.33 


m 


m 


[28] 20.33 


i 


i 



Table A.311: Void 

Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.312: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.313: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[261 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.314: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.314A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: IF A.162/47THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/28A - - Additional for 422 (Session Interval Too Small) response 

Table A.314B: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Min-SE 


[58] 5 


c1 


c1 


[58] 5 


c1 


c1 


c1: IF A.1 62/52 THEN m ELSE n/a --the SIP session timer. 



Table A.31 5: Void 

Prerequisite A. 163/23 - - UPDATE response 

Table A.316: Supported message bodies within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.3 Profile definition for the Session Description Protocol 
as used in the present document 

A.3.1 Introduction 

Void. 



A.3. 2 User agent role 



This subclause contains the ICS proforma tables related to the user agent role. They need to be completed only for UA 
implementations. 

Prerequisite: A.2/1 — user agent role 
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A.3.2.1 Major capabilities 



Table A.317: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC Status 


Profile status 




Capabilities within main protocol 




















Extensions 








22 


integration of resource management 
and SIP? 


[30] [64] 





m 


23 


grouping of media lines 


[531 


c3 


c3 


24 


mapping of media streams to resource 
reservation flows 


[54] 





Cl 


25 


SDP bandwidth modifiers for RTCP 
bandwidth 


[56] 





o(NOTEI) 


26 


TCP-based media transport in the 
dession description protocol 


[83] 





c2 


c1: IF A.3/1 THEN m ELSE n/a--UE role. 

c2: IF A.3/1 OR A.3/6 OR A.3/7 THEN o ELSE n/a - - UE, MGCF, AS. 

c3: IF A. 31 7/24 THEN m ELSE o - - mapping of media streams to resource reservation flows. 


NOTE 1 : For "video" and "audio" media types that utilise RTP/RTCP, if the RTCP bandwidth level for the session is 
different than the default RTCP bandwidth as specified in RFC 3556 [56], then, it shall be specified. For 
other media types, it may be specified. 
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A.3.2.2 SDP types 



Table A.318:SDP types 



Item 


Type 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ret. 


RFC 
status 


Profile 
status 




Session level description 


1 


v= (protocol version) 


[39] 5.1 


m 


m 


[39] 5.1 


m 


m 


2 


0= (owner/creator and session 
identifier) 


[39] 5.2 


m 


m 


[39] 5.2 


m 


m 


3 


s= (session name) 


[39] 5.3 


m 


m 


[39] 5.3 


m 


m 


4 


i= (session information) 


[39] 5.4 





c2 


[39] 5.4 


m 


c3 


5 


u= (URI of description) 


[39] 5.5 





c4 


[39] 5.5 





n/a 


6 


e= (email address) 


[39] 5.6 





c4 


[39] 5.6 





n/a 


7 


p= (phone number) 


[39] 5.6 





c4 


[39] 5.6 





n/a 


8 


c= (connection information) 


[39] 5.7 


c5 


c5 


[39] 5.7 


m 


m 


9 


b= (bandwidth information) 


[39] 5.8 







(N0TE1) 


[39] 5.8 


m 


m 




Time description (one or more per description) 


10 


t= (time the session is active) 


[39] 5.9 


m 


m 


[39] 5.9 


m 


m 


11 


r= (zero or more repeat times) 


[39] 5.10 





c4 


[39] 5.10 





n/a 




Session level description (continued) 


12 


z= (time zone adjustments) 


[39] 5.11 





n/a 


[39] 5.11 





n/a 


13 


k= (encryption key) 


[39] 5.12 


X 


X 


[39] 5.12 


n/a 


n/a 


14 


a= (zero or more session 
attribute lines) 


[39] 5.13 








[39] 5.13 


m 


m 




Media description (zero or more per description) 


15 


m= (media name and 
transport address) 


[39] 5.14 








[39] 5.14 


m 


m 


16 


i= (media title) 


[39] 5.4 





c2 


[39] 5.4 





c3 


17 


c= (connection information) 


[39] 5.7 


Cl 


cl 


[39] 5.7 


c1 


cl 


18 


b= (bandwidth information) 


[39] 5.8 







(N0TE1) 


[39] 5.8 






19 


k= (encryption key) 


[39] 5.12 


X 


X 


[39] 5.12 


n/a 


n/a 


20 


a= (zero or more media 
attribute lines) 


[39] 5.13 








[39] 5.13 


m 


m 


c1: IF A.318/15 THEN m ELSE n/a. 
c2: IF A.3A/6 THEN X ELSE -- MGCF. 
c3: IF A.3A/6 THEN n/a ELSE m - - MGCF. 
c4: IF A.3A/6 THEN x ELSE n/a - - MGCF. 

c5: IF A.318/17 THEN o ELSE m - - "c=" contained in all media description. 

NOTE 1 : For "video" and "audio" media types that utilise RTP/RTCP, it shall be specified. For other media types, it 
may be specified. 
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Prerequisite A.318/14 OR A. 318/20 - - a= (zero or more session/media attribute lines) 

Table A.319: zero or more session / media attribute lines (a=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


category (a=cat) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


2 


keywords {a=keywds) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


3 


name and version of tool 
(a=tool) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


4 


packet time (a=ptime) 


[3916 


clO 


ClO 


[3916 


c11 


c11 


5 


maximum packet time 
(a=maxptime) 


[39] 6, 
[28A] 8 


clO 


ClO 


[39] 6, 
[28A] 8 


c11 


oil 


6 


receive-only mode 
(a=recvonly) 


[39] 6 








[39] 6 


m 


m 


7 


send and receive mode 
(a=sendrecv) 


[39] 6 








[39] 6 


m 


m 


8 


send-only mode (a=sendonly) 


[3916 








[3916 


m 


m 


8A 


Inactive mode (a=inactive) 


[39] 6 








[39] 6 


m 


m 


9 


whiteboard orientation 
(a=orient) 


[39] 6 


ClO 


ClO 


[39] 6 


c11 


oil 


10 


conference type {a=type) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


11 


character set (a=charset) 


[3916 


c8 


c8 


[3916 


c9 


c9 


12 


language tag (a=sdplang) 


[39] 6 








[39] 6 


m 


m 


13 


language tag (a=lang) 


[39] 6 








[39] 6 


m 


m 


14 


frame rate (a=framerate) 


[39] 6 


c10 


ClO 


[39] 6 


c11 


c11 


15 


quality (a=quality) 


[39] 6 


c10 


ClO 


[39] 6 


c11 


c11 


16 


format specific parameters 
(a=fmtp) 


[39] 6 


ClO 


ClO 


[39] 6 


c11 


oil 


17 


rtpmap attribute (a=rtpmap) 


[39] 6 


c10 


ClO 


[39] 6 


c11 


oil 


18 


current-status attribute 
(a=curr) 


[30] 5 


Cl 


cl 


[30] 5 


c2 


c2 


19 


desired-status attribute 
(a=des) 


[30] 5 


Cl 


cl 


[30] 5 


c2 


c2 


20 


confirm-status attribute 
(a=conf) 


[30] 5 


cl 


cl 


[30] 5 


c2 


c2 


21 


media stream identification 
attribute (a=mid) 


[53] 3 


c3 


c3 


[53] 3 


c4 


c4 


22 


group attribute (a=group) 


[5314 


c5 


c5 


[53] 3 


c6 


c6 


23 


setup attribute (a=setup) 


[8314 


c7 


c7 


[8314 


c7 


c7 


24 


connection attribute 
(a=connection) 


[83] 5 


c7 


c7 


[83] 5 


c7 


c7 


c1 : IF A.317/22 AND A.318/20 THEN o ELSE n/a - - integration of resource management and SIP, media level 

attribute name "a=". 
c2: IF A.317/22 AND A.318/20 THEN m ELSE n/a - - integration of resource management and SIP, media level 

attribute name "a=". 
c3: IF A.317/23 AND A.318/20 THEN o ELSE n/a - - grouping of media lines, media level attribute name "a=". 
c4: IF A.317/23 AND A.318/20 THEN m ELSE n/a - - grouping of media lines, media level attribute name "a=". 
c5: IF A.317/23 AND A.318/14 THEN o ELSE n/a - - grouping of media lines, session level attribute name "a=". 
c6: IF A.317/23 AND A.318/14 THEN m ELSE n/a - - grouping of media lines, session level attribute name 

"a=". 
c7: IF A.317/26 AND A.318/20 THEN m ELSE n/a - - TCP-based media transport in the dession description 

protocol, media level attribute name "a=". 
c8: IF A.318/14 THEN o ELSE x - - session level attribute name "a=". 
c9: IF A.318/14 THEN m ELSE n/a - - session level attribute name "a=". 
clO: IF A.318/20 THEN o ELSE x - - media level attribute name "a=". 
c1 1 : IF A.318/20 THEN m ELSE n/a - - media level attribute name "a=". 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 



332 



ETSI TS 124 229 V7.6.0 (2006-12) 



A.3.2.3 Void 



A.3.2.4 Void 



Table A.320: Void 
Table A.321 : Void 
Table A.322: Void 
Table A.323: Void 
Table A.324: Void 
Table A.325: Void 
Table A.326: Void 
Table A.327: Void 

Table A.327A: Void 



A.3.3 Proxy role 

This subclause contains the ICS proforma tables related to the user role. They need to be completed only for proxy 
implementations. 

Prerequisite: A.2/2 — proxy role 



A.3.3. 1 Major capabilities 



Table A.328: Major capabilities 



Item 


Does the Implementation support 


Reference 


RFC Status 


Profile status 




Capabilities within main protocol 








OA 


application of session policy 


6.2, 6.3 


X 


c2 




Extensions 








1 


integration of resource management 
and SIP? 


[30] [64] 





n/a 


2 


grouping of media lines 


[53] 


c3 


c3 


3 


mapping of media streams to resource 
reservation flows 


[54] 





Cl 


4 


SDP bandwidth modifiers for RTCP 
bandwidth 


[56] 





c1 


5 


TCP-based media transport in the 
session description protocol 


[83] 





c1 


c1 : IF A.3/2 THEN m ELSE n/a - - P-CSCF role. 

c2: IF A.3/2 OR A.3/4 THEN o ELSE x - P-CSCF, S-CSCF. 

c3: IF A.328/3 THEN m ELSE o - - mapping of media streams to resource reservation flows. 
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A.3.3.2 SDP types 



Table A.329: SDP types 



Item 


Type 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ret. 


RFC 
status 


Profile 
status 




Session level description 


1 


v= (protocol version) 


[39] 5.1 


m 


m 


[39] 5.1 


m 


m 


2 


0= (owner/creator and session 
identifier). 


[39] 5.2 


m 


m 


[39] 5.2 


i 


i 


3 


s= (session name) 


[39] 5.3 


m 


m 


[39] 5.3 






4 


i= (session information) 


[39] 5.4 


m 


m 


[39] 5.4 






5 


u= (URI of description) 


[39] 5.5 


m 


m 


[39] 5.5 






6 


e= (email address) 


[39] 5.6 


m 


m 


[39] 5.6 






7 


p= (phone number) 


[39] 5.6 


m 


m 


[39] 5.6 






8 


c= (connection information) 


[39] 5.7 


m 


m 


[39] 5.7 






9 


b= (bandwidth information) 


[39] 5.8 


m 


m 


[39] 5.8 








Time description (one or more per description) 


10 


t= (time the session is active) 


[39] 5.9 


m 


m 


[39] 5.9 


i 


i 


11 


r= (zero or more repeat times) 


[39] 5.10 


m 


m 


[39] 5.10 


i 


i 




Session level description (continued) 


12 


z= (time zone adjustments) 


[39] 5.11 


m 


m 


[39] 5.1 1 






13 


k= (encryption key) 


[39] 5.12 


m 


m 


[39] 5.12 






14 


a= (zero or more session 
attribute lines) 


[39] 5.13 


m 


m 


[39] 5.13 








Media description (zero or more per description) 


15 


m= (media name and 
transport address) 


[39] 5.14 


m 


m 


[39] 5.14 


m 


m 


16 


i= (media title) 


[39] 5.4 


m 


m 


[39] 5.4 




i 


17 


c= (connection information) 


[39] 5.7 


m 


m 


[39] 5.7 




i 


18 


b= (bandwidth information) 


[39] 5.8 


m 


m 


[39] 5.8 




Cl 


19 


k= (encryption key) 


[39] 5.12 


m 


m 


[39] 5.12 




i 


20 


a= (zero or more media 
attribute lines) 


[39] 5.13 


m 


m 


[39] 5.13 




cl 


c1: IF A.328/0A THEN m ELSE i -- application of session policy. 
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Prerequisite A.329/14 OR A. 329/20 - - a= (zero or more session/media attribute lines) 

Table A.330: zero or more session / media attribute lines (a=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


category (a=cat) 


[39] 6 


m 


m 


[39] 6 






2 


l<eywords {a=keywds) 


[39] 6 


m 


m 


[39] 6 






3 


name and version of tool 
(a=tool) 


[39)6 


m 


m 


[39] 6 






4 


packet time (a=ptime) 


[3916 


m 


m 


[3916 


i 


c9 


5 


maximum packet time 
(a=maxptime) 


[39] 6, 
[28A] 8 


m 


m 


[39] 6, 
[28A] 8 


i 


c9 


6 


receive-only mode 
(a=recvonly) 


[39] 6 


m 


m 


[39] 6 


i 


c9 


7 


send and receive mode 
(a=sendrecv) 


[39] 6 


m 


m 


[39] 6 


i 


c9 


8 


send-only mode (a=sendonly) 


[3916 


m 


m 


[3916 




c9 


8A 


Inactive mode (a=inactive) 


[39] 6 


m 


m 


[39] 6 




c9 


9 


whiteboard orientation 
(a=orient) 


[39] 6 


m 


m 


[39] 6 




c9 


10 


conference type (a=type) 


[39] 6 


m 


m 


[39] 6 




i 


11 


character set (a=charset) 


[3916 


m 


m 


[3916 




i 


12 


language tag (a=sdplang) 


[39] 6 


m 


m 


[39] 6 




c9 


13 


language tag (a=lang) 


[39] 6 


m 


m 


[39] 6 




c9 


14 


frame rate (a=framerate) 


[39] 6 


m 


m 


[39] 6 




c9 


15 


quality (a=quality) 


[39] 6 


m 


m 


[39] 6 




c9 


16 


format specific parameters 
(a=fmtp) 


[39] 6 


m 


m 


[39] 6 




c9 


17 


rtpmap attribute (a=rtpmap) 


[39] 6 


m 


m 


[39] 6 


i 


c9 


18 


current-status attribute 
(a=curr) 


[30] 5 


m 


m 


[30] 5 


c2 


c2 


19 


desired-status attribute 
(a=des) 


[30] 5 


m 


m 


[30] 5 


c2 


c2 


20 


confirm-status attribute 
(a=conf) 


[30] 5 


m 


m 


[30] 5 


c2 


c2 


21 


media stream identification 
attribute (a=mid) 


[53] 3 


c5 


c5 


[53] 3 


c6 


c6 


22 


group attribute (a=group) 


[5314 


c5 


c5 


[5314 


c6 


c6 


23 


setup attribute (a=setup) 


[8314 


c7 


c7 


[8314 


c8 


c8 


24 


connection attribute 
(a=connection) 


[83] 5 


c7 


c7 


[83] 5 


c8 


c8 


c2: IF A.328/1 THEN m ELSE i - - integration of resource management and SIP. 

c5: IF A.328/2 THEN m ELSE n/a - - grouping of media lines. 

g6: if A.328/3 THEN m ELSE IF A.328/2 THEN i ELSE n/a - - mapping of media streams to resource 

reservation flows, grouping of media lines. 
c7: IF A.328/5 THEN m ELSE n/a. 
c8: IF A.328/5 THEN i ELSE n/a. 
c9: IF A.329/20 AND A.328/0A THEN m ELSE i - - media level attribute name "a=" and application of session 

policy. 



A.3.3.3 Void 



Table A.331 : Void 
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Table A.332: Void 
Table A.333: Void 
Table A.334: Void 
Table A.335: Void 
Table A.336: Void 
Table A.337: Void 
Table A.338: Void 

Table A.339: Void 
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A.4 Profile definition for other message bodies as used in 
the present document 

Void. 
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Annex B (normative): 

IP-Connectivity Access Network specific concepts when 

using GPRS to access IIVI CN subsystem 

B.1 Scope 

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) 
Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description 
Protocol (SDP), where the IP -CAN is General Packet Radio Service (GPRS). 

B.2 GPRS aspects when connected to the IIVI CN 
subsystem 

B.2.1 Introduction 

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by GPRS to 
provide packet-mode communication between the UE and the IM CN subsystem. 

Requirements for the UE on the use of these packet-mode services are specified in this clause. Requirements for the 
GGSN in support of this communication are specified in 3GPP TS 29.061 [11] and 3GPP TS 29.207 [12]. 

When using the GPRS, each IP-CAN bearer is provided by a PDP context. 

B.2.2 Procedures at the UE 

B. 2.2.1 PDP context activation and P-CSCF discovery 

Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 [4] and 3GPP TS 27.060 [lOA]. This PDP context shall remain active throughout the period the 
UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As 
a result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 

The UE shall choose one of the following options when performing establishment of this PDP context: 

I. A dedicated PDP context for SIP signalling: 

The UE shall indicate to the GGSN that this is a PDP context intended to carry IM CN subsystem-related 
signalling only by setting the IM CN Subsystem Signalling Flag. The UE may also use this PDP context for 
DNS and DHCP signalling according to the static packet filters as described in 3GPP TS 29.061 [11]. The 
UE can also set the Signalling Indication attribute within the QoS IE; 

II. A general-purpose PDP context: 

The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signaling. The 
UE shall indicate to the GGSN that this is a general-purpose PDP context by not setting the IM CN 
Subsystem Signalling Flag. The UE may carry both signalling and media on the general-purpose PDP 
context. The UE can also set the Signalling Indication attribute within the QoS IE. 
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The UE indicates the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options IE of 
the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT REQUEST 
message. Upon successful signalling PDP context establishment the UE receives an indication from GGSN in the form 
of IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE. If the flag is not received, the UE 
shall consider the PDP context as a general-purpose PDP context. 

The encoding of the IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE is described in 
3GPPTS 24.008 [8]. 

The UE can indicate a request for prioritised handling over the radio interface by setting the Signalling 
Indication attribute (see 3GPP TS 23.107 [4A]). The general QoS negotiation mechanism and the encoding of 
the Signalling Indication attribute within the QoS IE are described in 3GPP TS 24.008 [8]. 

NOTE: A general-purpose PDP Context may carry both IM CN subsystem signaling and media, in case the media 
does not need to be authorized by Service Based Local Policy mechanisms defined in 
3GPP TS 29.207 [12] and the media stream is not mandated by the P-CSCF to be carried in a separate 
PDP Context. 

c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315 [40], the DHCPv6 options for 
SIP servers RFC 3319 [41] and DHCPv6 options for Domain Name Servers (DNS) RFC 3646 [56C] as 
described in subclause 9.2.1. 

II. Transfer P-CSCF address(es) within the PDP context activation procedure. 

The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 
CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 
address with the highest priority. 

The UE can freely select method I or II for P-CSCF discovery. In case method I is selected and several P-CSCF 
addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as indicated 
in RFC 3319 [41]. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF 
address by the UE is implementation specific. 

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either ignore 
the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP request according 
to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 3315 [40] and RFC 3646 [56C] or by the Protocol 
Configuration Options IE when activating a PDP context according to 3GPP TS 27.060 [lOA]. 

The encoding of the request and response for IPv6 address(es) for DNS server(s) and list of P-CSCF address(es) within 
the Protocol Configuration Options IE is described in 3GPP TS 24.008 [8]. 

B.2.2.1 A Modification of a PDP context used for SIP signalling 

The PDP context shall not be modified from a dedicated PDP context for SIP signalling to a general-purpose PDP 
context or vice versa. The IM CN Subsystem Signalling Flag shall not be set in the Protocol Configuration Options IE 
of the MODIFY PDP CONTEXT REQUEST message. 

The UE shall not indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration Options IE 
of the MODIFY PDP CONTEXT REQUEST message. The UE shall ignore P-CSCF address(es) if received from the 
GGSN in the Protocol Configuration Options IE of the MODIFY PDP CONTEXT RESPONSE message. 
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B.2.2.1 B Re-establishment of the PDP context for signalling 

If the dedicated PDP context for SIP signalling is lost due to e.g. a GPRS routeing area update procedure, the UE shall 
attempt to re-establish the dedicated PDP context for SIP signalling. If this procedure does not succeed, the UE shall 
deactivate all PDP contexts established as a result of SIP signalling according to the 3GPP TS 24.008 [8]. 

B.2.2.2 Session management procedures 

The existing procedures for session management as described in 3GPP TS 24.008 [8] shall apply while the UE is 
connected to the IM CN subsystem. 

B.2.2.3 Mobility management procedures 

The existing procedures for mobility management as described in 3GPP TS 24.008 [8] shall apply while the UE is 
connected to the IM CN subsystem. 

B.2.2.4 Cell selection and lack of coverage 

The existing mechanisms and criteria for cell selection as described in 3GPP TS 25.304 [9] and 3GPP TS 44.018 [20] 
shall apply while the UE is connected to the IM CN subsystem. 

B. 2.2.5 PDP contexts for media 
B. 2. 2.5.1 General requirements 

The UE can establish media streams that belong to different SIP sessions on the same PDP context. 

During establishment of a session, the UE establishes data streams(s) for media related to the session. Such data 
stream(s) may result in activation of additional PDP context(s). Such additional PDP context(s) shall be established as 
secondary PDP contexts associated to the PDP context used for signalling. 

When the UE has to allocate bandwidth for RTP and RTCP in a PDP context, the UE shall use the rules outlined in 
3GPPTS 29.208 [13]. 

B.2.2.5.1 A Activation or modification of PDP contexts for media 

If the UE receives indication within the SDP according to RFC 3524 [54] that media stream(s) belong to group(s), the 
media stream(s) shall be set up on separate PDP contexts according to the indication of grouping of media streams. The 
UE may freely group media streams to PDP context(s) in case no indication of grouping of media streams is received 
from the P-CSCF. 

If the capabilities of the originating UE prevents it from establishment of additional PDP contexts according to the 
media grouping attributes given by the P-CSCF in accordance with RFC 3524 [54], the UE will not establish such 
grouping of media streams. Instead, the originating UE shall negotiate media parameters for the session according to 
RFC 3264 [27B]. 

If the capabilities of the terminating UE prevents it from establishment of additional PDP contexts according to the 
media grouping attributes given by the P-CSCF in accordance with RFC 3524 [54], the UE will not establish such 
grouping of media streams. Instead, the terminating UE shall the UE shall handle such SDP offers in accordance with 
RFC 3388 [53]. 

The UE can receive a media authorization token in the P-Media- Authorization header from the P-CSCF according to 
RFC 3313 [31]. If a media authorization token is received in the P-Media-Authorization header when a SIP session is 
initiated, the UE shall: 

either use existing PDP context(s) where another media authorization token is already in use and no indication of 
grouping of media streams is required; or 

establish separate PDP context(s) for the media; or 
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use an existing PDP context where media authorization token is not in use and no indication of grouping of 
media streams is required. 

When a UE modifies a PDP context to indicate a new media authorization token: 

either as a resuh of establishment of an additional SIP session; or 

modification of media streams for an ongoing SIP session; 

the UE shall include all media authorization tokens and all flow identifiers for all ongoing SIP sessions that use this 
particular PDP context. 

If a media authorization token is received in subsequent messages for the same SIP session, the UE shall: 

use the existing PDP context(s) for media; 

modify the existing PDP context(s) for media; or 

establish additional PDP context(s) for media. 

If either background or interactive QoS class is needed for the media, then the UE does not need to use the authorization 
token even if it receives one. In this case the UE may reuse an existing PDP context and it does not need to request PDP 
context modification unless it needs to modify the QoS. 

If existing PDP context(s) where another media authorization token is already in use is re-used for the media, or 
separate PDP context(s) is established for the media, the UE shall proceed as follows: 

when a SIP session is terminated, the media authorization token is no longer valid and the UE shall not include it 
in future GPRS session management messages. The UE shall send a MODIFY PDP CONTEXT REQUEST 
message updating the binding information by deleting the media authorization token and the corresponding flow 
identifiers that are no longer valid. If a SIP session is terminated and no other SIP sessions are using the PDP 
context, the UE shall either update the binding information as described above or deactivate the PDP context; 

the UE shall transparently pass the media authorization token received from the P-CSCF in a response to an 
INVITE request at originating setup or in the INVITE request at terminating setup to the GGSN. The UE shall 
signal it by inserting it within the Traffic Flow Template IE in the ACTIVATE SECONDARY PDP CONTEXT 
REQUEST message or the MODIFY PDP CONTEXT REQUEST message; 

to identify to the GGSN which flow(s) (identified by m-lines within the SDP) that are transferred within a 
particular PDP context, the UE shall set the flow identifier(s) within the Traffic Flow Template IE in the 
ACTIVATE SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST 
message. Detailed description of how the flow identifiers are constructed is provided in 3GPP TS 29.207 [12]; 

if the UE receives several media authorization tokens from the P-CSCF within the same SIP request or response, 
the first instance of the media authorization token shall be sent to the GGSN, and subsequent instances are 
discarded by the UE; and 

the UE shall not include the IM CN Subsystem Signalling Flag when a PDP context for media is established or 
modified. 

The encoding of the media authorization token and the flow identifiers within the Traffic Flow Template IE is described 
in3GPPTS24.008[8]. 

B. 2. 2.5. 2 Special requirements applying to forked responses 

Since the UE does not know that forking has occurred until a second, provisional response arrives, the UE sets up the 
PDP context(s) as required by the initial response received. If a subsequent provisional response is received, different 
alternative actions may be performed depending on the requirements in the SDP answer: 

1) the bearer requirements of the subsequent SDP can be accommodated by the existing PDP context(s). The UE 
performs no activation or modification of PDP contexts. 

2) the subsequent SDP introduces different QoS requirements or additional IP flows. The UE modifies the existing 
PDP context(s), if necessary, according to subclause B. 2. 2. 5.1 A. 
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3) the subsequent SDP introduces one or more additional IP flows. The UE establishes additional PDF context(s) 
according to subclause B. 2. 2. 5.1 A. 

NOTE 1: When several forked responses are received, the resources requested by the UE is are the "logical OR" of 
the resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE 
does not request more resources than proposed in the original INVITE request. 

NOTE 2: When service-based local policy is applied, the UE receives the same authorization token for all forked 
requests/responses related to the same SIP session. 

When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The UE shall 
release all the unneeded radio/bearer resources. Therefore, upon the reception of the first final 200 (OK) response for 
the INVITE request (in addition to the procedures defined in RFC 3261 [26] subclause 13.2.2.4), the UE shall: 

1) in case PDP context(s) were established or modified as a consequence of the INVITE request and forked 
provisional responses that are not related to the accepted 200 (OK) response, delete the PDP context(s) or 
modify the delete the PDP context(s) back to their original state. 

B. 2. 2.5.3 Unsuccessful situations 

One of the Go interface related error codes can be received by the UE in the ACTIVATE SECONDARY PDP 
CONTEXT REJECT message or the MODIFY PDP CONTEXT REJECT message. If the UE receives a Go interface 
related error code, the UE shall either terminate the session or retransmit the message up to three times. The Go 
interface related error codes are further specified in 3GPP TS 29.207 [12]. 



B.2.2.6 Emergency service 



Editor's note: The UE will attach to the network and perform PDP context activation according to the procedures 
described in 3GPP TS 23.060 and 3GPP TS 23.167. This subclause will describe these changes as 
outlined by 3GPP TS 24.008. 



B.3 Application usage of SIP 

B.3.1 Procedures at the UE 

B.3. 1 . 1 P-Access-Network-lnfo header 

The UE shall always include the P- Access-Network-Info header where indicated in subclause 5.1. 

B.3.2 Procedures at the P-CSCF 

Editor"s Note: Move here the MNC/MCC related text from 5.2.10.1. 

B.4 3GPP specific encoding for SIP header extensions 
B.4.1 Void 
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Annex C (normative): 

UICC and USIM Aspects for access to the IM CN 

subsystem 

C.1 Scope 

This clause describes the UICC and USIM aspects for access to the IM CN subsystem. Additional requirements related 
to UICC usage for access to the IM CN subsystem are described in 3GPP TS 33.203 [19]. 



C.2 Derivation of IIVIS parameters from USIIVI 

In case the UE is loaded with a UICC that contains a USIM application but does not contain an ISIM application, the 
UE shall: 

generate a private user identity; 

generate a temporary public user identity; and 

generate a home network domain name to address the SIP REGISTER request to. 

All these three parameters are derived from the IMSI parameter in the USIM, according to the procedures described in 
3GPP TS 23.003 [3]. Also in this case, the UE shall derive new values every time the UICC is changed, and shall 
discard existing values if the UICC is removed. 

NOTE: If there is an ISIM and a USIM application on a UICC, the ISIM application is used for IMS 
authentication, as described in 3GPP TS 33.203 [19]. See subclause 5.1.1.1A. 



C.3 ISIIVI Location in 3GPP Systems 

For 3GPP systems, if ISIM application is present, it is contained in UICC. 
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Annex D (normative): 

IP-Connectivity Access Network specific concepts when 

using l-WLAN to access IIVI CN subsystem 

D.1 Scope 

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) 
Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description 
Protocol (SDP), where the IP -CAN is Wireless LAN Interworking (l-WLAN). 

D.2 l-WLAN aspects when connected to the IIVI CN 
subsystem 

D.2.1 Introduction 

A WLAN UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by I- 
WLAN to provide packet-mode communication between the WLAN UE and the IM CN subsystem. 

Requirements for the WLAN UE on the use of these packet-mode services are specified in this clause. Requirements for 
the PDG in support of this communication are specified in 3GPP TS 29.161 [IIC]. When using the I-WLAN, the IP- 
CAN bearer is provided by an l-WLAN tunnel. 

D.2.2 Procedures at the WLAN UE 

D.2.2.1 l-WLAN tunnel activation and P-CSCF discovery 

Prior to communication with the IM CN subsystem, the WLAN UE shall: 

a) Perform l-WLAN network selection i.e. gaining 3GPP Direct access as described in 3GPP TS 24.234 [8C] in the 
access dependent case; 

b) Establish an IKE security association and an IPsec ESP security association (l-WLAN tunnel with the PDG 
according to the W-APN and PDG selection criteria described in 3GPP TS 24.234 [8C]. The IKE security 
association and IPsec ESP security association (l-WLAN tunnel) shall remain active throughout the period the 
WLAN UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the 
deregistration.; 

The WLAN UE may carry both signalling and media on an IPsec ESP security association. 

c) Acquire a P-CSCF address(es). 

The method for P-CSCF discovery is: 

Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315 [40], the DHCPv6 options for SIP 
servers RFC 3319 [41] and the DHCP options for Domain Name Servers (DNS) RFC 3646 [56C] as described in 
subclause 9.2.1. 

In case several P-CSCF addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN 
shall be performed as indicated in RFC 3319 [41]. If sufficient information for P-CSCF address selection is not 
available, selection of the P-CSCF address by the WLAN UE is implementation specific. 

The WLAN UE may request a DNS Server IPv6 address(es) via RFC 3315 [40] and RFC 3646 [56C]. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 343 ETSI TS 1 24 229 V7.6.0 (2006-1 2) 

D.2.2.2 l-WLAN tunnel procedures 
D. 2. 2. 2.1 General requirements 

The WLAN UE can establish media streams that belong to different SIP sessions on the same I-WLAN tunnel. 

During establishment of a session, the WLAN UE establishes data streams(s) for media related to the session. Such data 
stream(s) may result in activation of additional IPsec ESP security associations (I-WLAN tunnels). 

D.2.2.2.2 Usage of I-WLAN tunnel for media 

If the WLAN UE receives indication within the SDP according to RFC 3524 [54] that media stream(s) belong to 
group(s), the media stream(s) shall be set up on separate IPSEC ESP security associations (I-WLAN tunnels) according 
to the indication of grouping of media streams. The WLAN UE may freely group media streams to IPsec ESP security 
association (I-WLAN tunnel(s)) in case no indication of grouping of media streams is received from the P-CSCF. 

If the capabilities of the originating WLAN UE, or operator policy at the PDG prevents the originating WLAN UE from 
establishment of additional IPsec ESP security associations (I-WLAN tunnels) according to the media grouping 
attributes given by the P-CSCF in accordance with RFC 3524 [54], the WLAN UE will not establish such grouping of 
media streams. Instead, the originating WLAN UE shall negotiate media parameters for the session according to 
RFC 3264 [27B]. 

If the capabilities of the terminating WLAN UE or operator policy at the PDG prevents the originating WLAN UE from 
establishment of additional IPsec ESP security associations (I-WLAN tunnels) according to the media grouping 
attributes given by the P-CSCF in accordance with RFC 3524 [54], the WLAN UE will not establish such grouping of 
media streams. Instead, the terminating WLAN UE shall handle such SDP offers in accordance with RFC 3388 [53]. 

The UE can receive a media authorization token in the P-Media- Authorization header from the P-CSCF according to 
RFC 3313 [31]. If a media authorization token is received in the P-Media-Authorization header when a SIP session is 
initiated, the UE shall reuse the existing I-WLAN tunnel and ignore the media authorization token. 

D.2.2.2. 3 Special requirements applying to forked responses 

Since the UE is unable to perform bearer modification, forked responses place no special requirements on the UE. 

D.2.2.3 Emergency service 

No particular requirements apply to emergency calls. 

D.3 Application usage of SIP 

D.3.1 Procedures at the UE 
D.3. 1.1 P-Access-Network-lnfo header 

The UE shall always include the P-Access-Network-Info header where indicated in subclause 5.1. 

D.3.2 Procedures at the P-CSCF 

Editor"s Note: If access specific part of subclause 5.2.10.1 is removed, the case when no MNC/MCC codes are 
available, must be described here. 
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Annex E (normative): 

IP-Connectivity Access Network specific concepts when 

using xDSL to access IIVI CN subsystem 

E.1 Scope 

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) 
Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description 
Protocol (SDP), where the IP -CAN is xDSL. 



E.2 xDSL aspects when connected to the IIVI CN 
subsystem 

E.2.1 Introduction 

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the xDSL 
access network to provide packet-mode communication between the UE and the IM CN subsystem. 

Requirements for the BRAS in support of this communication are outside the scope of this document and specified 
elsewhere. 

From the UEs perspective, it is assumed that one or more IP-CAN bearer(s) are provided, in the form of connection(s) 
managed by the DSL modem supporting the UE. 

In the first instance, it is assumed that the IP-CAN bearer(s) is (are) statically provisioned between the UE and the 
BRAS according to the user's subscription. 

It is out of the scope of the current Release to specify whether a single IP-CAN bearer is used to convey both signalling 
and media flows, or whether several PVC connections are used to isolate various types of IP flows (signalling flows, 
conversational media, non conversational media...). 

The end-to-end characteristics of the xDSL IP-CAN bearer depend on the type of regional access network, and on 
network configuration. The description of the network PVC termination (e.g., located in the DSLAM, in the BRAS...) 
is out of the scope of this annex. 

E.2.2 Procedures at the UE 
E. 2.2.1 P-CSCF discovery 
E.2.2.1 .1 P-CSCF discovery 

Prior to communication with the IM CN subsystem, the UE shall perform a Network Attachment procedure using 
DHCP mode or PPP mode. When using xDSL, both IPv4 and IPv6 UEs may access the IM CN subsystem. The UE may 
request a DNS Server IPv4 address(es) via RFC 2132 [20F] or a DNS Server IPv6 address(es) via RFC 3315 [40]. 

E.2.2.1 .2 Procedure at the UE when using IPv4 

The UE may acquires a P-CSCF address(es) by using the DHCP (see RFC 2132 [20F]), the DHCPv4 options for SIP 
servers (see RFC 3361 [35 A]), and RFC 3263 [27 A]. 
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In case the DHCP server provides several P-CSCF addresses or FQDNs to the UE, the UE shall select the P-CSCF 
address or FQDN as indicated in RFC 3361 [35 A]. If sufficient information for P-CSCF address selection is not 
available, selection of the P-CSCF address by the UE is implementation specific. 

E.2.2.1 .3 Procedure at the UE when using IPv6 

The UE may acquires a P-CSCF address(es) by using the DHCPv6 (see RFC 3315 [40] and RFC 3646 [56C]), the 
DHCPv6 options for SIP servers (see RFC 3319 [41]), and RFC 3263 [27H]. 

In case the DHCP server provides several P-CSCF addresses or FQDNs to the UE, the UE shall select the P-CSCF 
address or FQDN as indicated in RFC 3319 [41]. If sufficient information for P-CSCF address selection is not available, 
selection of the P-CSCF address by the UE is implementation specific. 

E.2.2.2 xDSL bearer provisioning 

E. 2. 2.2.1 Statically provisioned xDSL bearer(s) 

xDSL bearer(s) is (are) statically provisioned in the current Release. 

E.2.2.2.2 xDSL bearer(s) for media 
E. 2. 2. 2. 2.1 General requirements 

The UE can establish media streams that belong to different SIP sessions on the same xDSL bearer. 

E.2.2.2. 2. 2 Media grouping 

If the UE receives indication within the SDP according to RFC 3524 [54] that media stream(s) belong to group(s), and 
if several xDSL bearers are available to the UE for the session, the media stream(s) may be sent on separate xDSL 
bearers according to the indication of grouping. The UE may freely group media streams to xDSL bearers in case no 
indication of grouping is received from the P-CSCF. 

If the UE receives media grouping attributes in accordance with RFC 3524 [54] that it cannot provide within the 
available xDSL bearer(s), then the UE shall handle such SDP offers in accordance with RFC 3388 [53]. 

E.2.2.2. 2. 3 Media authorization 

The UE can receive a media authorization token in the P-Media- Authorization header from the P-CSCF according to 
RFC 3313 [31]. If a media authorization token is received in the P-Media-Authorization header when a SIP session is 
initiated, the UE shall reuse the existing xDSL bearer(s) and ignore the media authorization token. 

E.2.2.2. 2.4 Special requirements applying to forked responses 

Since the UE is unable to perform bearer modification, forked responses place no special requirements on the UE. 

E.2.2.3 Emergency service 

No particular requirements apply to emergency calls. 
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E.3 Application usage of SIP 

E.3.1 Procedures at the UE 

E.3. 1 . 1 P-Access-Network-lnfo header 

The UE may, but need not, include the P-Access-Network-Info header where indicated in subclause 5.1. 

E.3.2 Procedures at the P-CSCF 

Editor"s Note: If access specific part of subclause 5.2.10.1 is removed, the case when no MNC/MCC codes are 
available, must be described here. 

E.3.2. 1 Location information inandling 

Upon receipt of an INVITE request, the P-CSCF based on local policy may include a dsl-location parameter in P- 
Access-Network-Info header.The value of the dsl-location parameter shall be the value as received in the Location- 
Information header in the User-Data Answer command as specified in ETSI ES 283 035 [98]. 

The way the P-CSCF deduce that the request comes from a fixed broadband UE is implementation dependent. 
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Annex F (normative): 

Additional procedures in support for hosted NAT 

NOTE: This subclause describes the mechanism for support of the hosted NAT scenario. This does not preclude 
other mechanisms but they are out of the scope of this annex. 

F.1 Scope 

This annex describes the UE and P-CSCF procedures in support of hosted NAT. In this scenario, both the media flows 
and the SIP signalling both traverse a NA(P)T device located in the customer premises domain. The term "hosted NAT" 
is used to address this function. 

When receiving an initial SIP REGISTER request without integrity protection, the P-CSCF can, determine whether to 
perform the hosted NAT procedures for the user identified by the REGISTER request by comparing the address 
information in the top-most SIP Via header with the IP level address information from where the request was received. 
The P-CSCF will use the hosted NAT procedure only when the address information do not match. 

NOTE: There is no need for the P-CSCF to resolve a domain name in the Via header when UDP encapsulated 
tunnel mode for IPsec is used. The resolution of a domain name in the Via header is not required by 
RFC 3261 [26]. 

In order to provide hosted NAT traversal for SIP REGISTER requests without integrity protection and the associated 
responses, the P-CSCF makes use of the "received" and "rport" header field parameters as described in RFC 3261 [26] 
and RFC 3581 [56A]. The hosted NAT traversal for protected SIP messages is provided by applying UDP 
encapsulation to IPSec packets in accordance with RFC 3948 [63 A]. 

Alternativly to the procedures defined in subclause F.2 which are employed to support the hosted NAT scenario where 
the security solution is based on UDP encapsulated IPSec as defined in 3GPP TS 33.203 [19], subclause F.4 provides 
procedures for NAT traversal for security solutions that are not defined in 3GPP TS 33.203 [19]. Use of such security 
solutions is outside the scope of this document. 



F.2 Application usage of SIP 
F.2.1 UE usage of SIP 



F.2. 1.1 General 

This subclause describes the UE SIP procedures for supporting hosted NAT scenarios. The description enhances the 
procedures specified in subclause 5.1. 

The UE shall support the symmetric response routing mechanism according to RFC 3581 [56A]. 

F.2.1 .2 Registration and autinentication 
F.2.1. 2.1 General 

The text in subclause 5.1.1.1 applies without changes 

F.2.1 .2.1 A Parameters contained in the ISIM 

The text in subclause 5. 1.1.1 A applies without changes 
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F.2.1.2.2 Initial registration 

The procedures described in subclause 5.1.1.2 apply with the additional procedures described in the present subclause. 

NOTE 1: In accordance with the definitions given in subclause 3.1 the IP address aquired initially by the UE in a 
hosted NAT scenario is the UE private IP address. 

On sending a REGISTER request, the UE shall populate the header fields as indicated in subitems a) through]) of 
subclause 5.1.1.2 with the exceptions of subitems d), e) and h) which are modified as follows 

The UE shall populate: 

d) a Contact header according to the following rules: if the REGISTER request is sent without integrity protection, 
the Contact header shall be set to include SIP URI(s) containing the private IP address of the UE in the hostport 
parameter or FQDN. If the REGISTER request is integrity protected, the UE shall include the public IP address 
or FQDN and the protected server port value in the hostport parameter. The UE shall only use a FQDN in a 
protected REGISTER request, if it is ensured that the FQDN resolves to the public IP address of the NAT; 

NOTE 2: The UE will learn its public IP address from the received parameter in the topmost Via header in the 401 
(Unauthorized) response to the unprotected REGISTER request. 

e) a Via header according to the following rules: if the REGISTER request is sent without integrity protection, the 
Via header shall be set to include the private IP address or FQDN of the UE in the sent-by field. If the 
REGISTER request is integrity protected, the UE shall include the public IP address or FQDN and the protected 
server port value in the sent-by field. The UE shall only use a FQDN in a protected REGISTER request, if it is 
ensured that the FQDN resolves to the public IP address of the NAT; 

NOTE 3: If the UE specifies a FQDN in the host parameter in the Contact header and in the sent-by field in the Via 
header of an unprotected REGISTER request, this FQDN will not be subject to any processing by the P- 
CSCF or other IMS entities. The means to ensure that the FQDN resolves to the public IP address of the 
NAT are outside of the scope of this specification. One option for resolving this is local configuration. 

h) the Security-Client header field set to specify the security mechanism the UE supports, the IPsec layer 

algorithms the UE supports and the parameters needed for the security association setup. The UE shall support 
the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters 
needed for the security association setup is specified in Annex H of 3GPP TS 33.203 [19]. The UE shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPSec layer 
algorithms for integrity protection and for encryption as defined in 3GPP TS 33.203 [19], and shall announce 
support for them according to the procedures defined in RFC 3329 [48]. In addition to transport mode the UE 
shall support UDP encapsulated tunnel mode as per RFC 3948 [63A] and shall announce support for both modes 
as described in TS 33.203 [19]; 

When a 401 (Unauthorized) response to a REGISTER is received and this response is received without integrity 
protection, the procedures described in subclause 5.1.1.2 apply with the following additions: 

The UE shall check whether a received parameter is present in the topmost Via header. 

If no received parameter is present, the UE shall proceed with the procedures described in subclause 5. 1 of the 
main body of this specification; 

If a received parameter is present, the UE shall verify using the Security-Server header that mode "UDP-enc-tun" 
is selected. If the verification succeeds the UE shall store the IP address contained in the received parameter as 
the UE public IP address. If the verification does not succeed the UE shall abort the registration. 

In addition, when a 401 (Unauthorized) response to a REGISTER is received (with or without integrity protection) the 
UE shall behave as described in subclause F.2.1.2.5. 

F.2.1 .2.3 Initial subscription to the registration-state event package 

The procedures described in subclause 5.1.1.3 apply with the additional procedures described in the present subclause. 

On sending a SUBSCRIBE request, the UE shall populate the header fields as indicated in subclause 5.1.1.2 with the 
exception of subitem g) which is modified as follows 

The UE shall populate: 
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g) a Contact header set to contain the UE public IP address or FQDN, and with the protected server port value as in 
the initial registration. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP 
address of the NAT. 

NOTE: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope 
of this specification. One option for resolving this is local configuration. 

F. 2. 1.2.4 User-initiated re-registration 

The procedures described in subclause 5.1.1.4 apply with the additional procedures described in the present subclause. 

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as 
indicated in subclause 5.1.1.4 with the exception of subitems d) and e) which are modified as follows. 

The UE shall populate: 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the public IP address of the 
UE or FQDN and protected server port value bound to the security association. The UE shall only use a FQDN, 
if it is ensured that the FQDN resolves to the public IP address of the NAT; 

e) a Via header set to include the public IP address or FQDN of the UE in the sent-by field and the protected server 
port value bound to the security association. The UE shall only use a FQDN, if it is ensured that the FQDN 
resolves to the public IP address of the NAT; 

NOTE: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope 
of this specification. One option for resolving this is local configuration. 

F.2.1.2.5 Authentication 
F.2.1. 2.5.1 General 

The procedures of subclause 5.1.1.5.1 apply with with the additional procedures described in the present subclause. 

On receiving a 401 (Unauthorized) response to the REGISTER request and the response is deemed to be valid, the UE 
shall behave as of subclause 5.1.1.5.1 with the exception of subitem 3) which is modified as follows. 

The UE shall: 

3) send another REGISTER request using the temporary set of security associations to protect the message. The 
header fields are populated as defined for the initial request (see subclause F.2. 1 .2.2), with the addition that the 
UE shall include an Authorization header containing the private user identity and the authentication challenge 
response calculated by the UE using RES and other parameters, as described in RFC 3310 [49]. The UE shall 
also insert the Security-Client header that is identical to the Security-Client header that was included in the 
previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 
(Unauthorized) response). The UE shall also insert the Security-Verify header into the request, by mirroring in it 
the content of the Security-Server header received in the 401 (Unauthorized) response. The UE shall set the Call- 
ID of the integrity protected REGISTER request which carries the authentication challenge response to the same 
value as the Call-ID of the 401 (Unauthorized) response which carried the challenge. 

Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security 
associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The 
UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security 
associations. The UE should send an unprotected REGISTER message according to the procedure specified in 
subclause F.2.1. 2.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF. 

F.2.1 .2.5.2 Network initiated re-authentication 

The procedures of subclause 5.1.1 .5.2 apply with with the additional procedures described in the present subclause. 

On starting the re-authentication procedure sending a REGISTER request that does not contain a challenge response, 
the UE shall behave as of subclause 5.1.1.5.2 with the exception of subitem 2) which is is modified as follows. 

The UE shall: 
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2) start the re-authentication procedures at the appropriate time (as a resuh of the S-CSCF procedure described in 
subclause 5.4.1.6) by initiating a reregistration as described in subclause F.2. 1.2.4, if required. 

F. 2. 1.2. 5. 3 Abnormal cases 

The text in subclause 5.1.1.5.3 applies without changes. 

F.2.1 .2.5A Change of IPv6 address due to privacy 

The text in subclause 5.1.1.5A applies without changes. 

F.2.1 .2.6 User-initiated deregistration 

The procedures of subclause 5.1.1.6 apply with with the additional procedures described in the present subclause. 

On sending a REGISTER request, the UE shall populate the header fields as indicated in subclause 5.1.1.6 with the 
exception of subitems d) and e) which is modified as follows. 

The UE shall populate: 

d) a Contact header set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP 
address of the UE or FQDN and the protected server port value bound to the security association. The UE shall 
only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; 

e) a Via header set to include the IP address or FQDN of the UE in the sent-by field and the protected server port 
value bound to the security association. The UE shall only use a FQDN, if it is ensured that the FQDN resolves 
to the public IP address of the NAT; 

NOTE 1: In case of hosted NAT traversal only the UE public IP addresses are bound to security associations. 

NOTE 2: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope 
of this specification. One option for resolving this is local configuration. 

F.2.1. 2. 7 Network-initiated deregistration 

The procedures of subclause 5.1.1.7 apply with with the additional procedures described in the present subclause. 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as 
described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE with: 

the state attribute set to "terminated" and the event attribute set to "rejected" or "deactivated"; or 

the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to 
"terminated", and associated event attribute element to "rejected" or "deactivated"; 

The UE shall remove all registration details relating to these public user identities. In case of a "deactivated" event 
attribute, the UE shall start the initial registration procedure as described in subclause F.2. 1 .2.2. In case of a "rejected" 
event attribute, the UE shall release all dialogs related to those public user identities. 

F.2.1 .3 Subscription and notification 

The text in subclause 5.1.2 applies without changes. 

F.2.1 .4 Generic procedures applicable to all methods excluding the 
REGISTER method 

F.2.1 .4.1 UE originating case 

The procedures described in subclause 5.1.2A.1 apply with the additional procedures described in the present subclause. 
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When the UE sends any request, the requirements in subclause 5.1.2A. 1 are replaced by the following requirements. 
The UE shall include: 

a Via header set to include the public IP address of the UE or FQDN and the protected server port in the sent-by 
field. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the 
NAT; and 

the public IP address of the UE or FQDN and the protected server port in the hostport parameter in any Contact 
header that is otherwise included. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the 
public IP address of the NAT. 

NOTE: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope 
of this specification. One option for resolving this is local configuration. 

The UE shall discard any SIP response that is not integrity protected and is received from the P-CSCF outside of the 
registration and authentication procedures. The requirements on the UE within the registration and authentication 
procedures are defined in subclause F.2. 1.2.4. 

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F 
expired, as described in subclause F.2.1.2.3. 

F.2.1 .4.2 UE terminating case 

The procedures described in subclause 5.1.2A.2 apply with the additional procedures described in the present subclause. 

When the UE sends any response, the requirements in subclause 5.1.2A.1 are replaced by the following requirement. 
The UE shall: 

include the public IP address of the UE or FQDN and the protected server port in the hostport parameter in any 
Contact header that is otherwise included. The UE shall only use a FQDN, if it is ensured that the FQDN 
resolves to the public IP address of the NAT. 

NOTE: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope 
of this specification. One option for resolving this is local configuration. 

The UE shall discard any SIP request that is not integrity protected and is received from the P-CSCF outside of the 
registration and authentication procedures. The requirements on the UE within the registration and authentication 
procedures are defined in subclause F.2. 1 .2. 



F.2.2 P-CSCF usage of SIP 



F.2.2.1 Introduction 

This subclause describes the SIP procedures for supporting hosted NAT scenarios. 

The description enhances the procedures specified in subclause 5.2. 

The P-CSCF shall support the symmetric response routing mechanism according to RFC 3581 [56A]. 

NOTE : Symmetric response routing is used to support hosted NAT and applicable only to initial, unprotected 
REGISTER requests and corresponding responses. 

F.2.2.2 Registration 

The procedures described in subclause 5.2.2 apply with the additional procedures described in the present subclause. 

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall behave as of subclause 5.2.2 with the 
exception of subitem 5) and 6) which are modified as follows. 

The P-CSCF shall: 

5) in case the REGISTER request was received without integrity protection, then: 
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a) check the existence of the Security-Client header. If the header is not present, then the P-CSCF shall return a 
suitable 4xx response. If the header is present the P-CSCF shall: 

in case the UE indicated support for "UDP-enc-tun" then remove and store it. 

in case the UE does not indicate support for "UDP-enc-tun" then: 

if the host portion of the sent-by field in the topmost Via header contains an IP address that differs 
from the source address of the IP packet, silently drop the REGISTER; 

otherwise continue with procedures as of subclause 5.2.2. 

NOTE: If the UE does not indicate support for "UDP-enc-tun" and the P-CSCF detects that the UE is located 
behind a NAT device, then the P-CSCF can just drop the REGISTER to avoid unnecessary signalling 
traffic. 

b) if the host portion of the sent-by field in the topmost Via header contains a FQDN, or if it contains an IP 
address that differs from the source address of the IP packet, the P-CSCF shall add a received parameter in 
accordance with the procedure defined in RFC 3261 [26]. If the P-CSCF adds a received parameter, it shall 
also add an rport parameter in accordance with the procedure defined in RFC 3581 [56 A]. 

6) in case the REGISTER request was received integrity protected, then the P-CSCF shall: 

a) check the security association which protected the request. If the security association is a temporary one, the 
P-CSCF shall: 

in case the host parameter in the Contact address is in the form of a FQDN, ensure that the given FQDN 
will resolve (e.g., by reverse DNS lookup) to the IP address bound to the security association; 

in case the P-CSCF has detected earlier that the UE is located behind a NAT, retrieve port_Uenc from the 
encapsulating UDP header of the packet received and complete configuration of the temporary set of 
security associations by configuring port_Uenc in each of the temporary security associations; 

check whether the request contains a Security- Verify header in addition to a Security-Client header. If 
there are no such headers, then the P-CSCF shall return a suitable 4xx response. If there are such headers, 
then the P-CSCF shall compare the content of the Security- Verify header with the content of the Security- 
Server header sent earlier and the content of the Security-Client header with the content of the Security- 
Client header received in the challenged REGISTER. If those do not match, then there is a potential man- 
in-the-middle attack. The request should be rejected by sending a suitable 4xx response. If the contents 
match, the P-CSCF shall remove the Security- Verify and the Security-Client header; 

When the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request and this response 
contains a received and rport parameter in the Via header associated with the UE and the UE indicated support for 
"UDP-enc-tun" IPsec mode, the P-CSCF shall: 

1) delete any temporary set of security associations established towards the UE; 

2) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the proper private 
user identity and to the temporary set of security associations which will be setup as a result of this challenge. 
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK have been 
removed; 

3) insert a Security-Server header in the response, containing the P-CSCF security list and the parameters needed 
for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPSec layer 
algorithms for integrity protection and for encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall 
indicate "UDP-enc-tun" as the only IPsec mode; 

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P- 
CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel 
mode and shall leave the value for port-Uenc unspecified in each of the temporary security associations. For 
further details see 3GPP TS 33.203 [19] and RFC 3329 [48]. The P-CSCF shall set the temporary SIP level 
lifetime for the temporary set of security associations to the value of reg-await-auth timer; and 
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5) send the 401 (Unauthorized) response unprotected to the UE using the mechanisms described in RFC 3261 [26] 
and RFC 3581 [56A], i.e. the P-CSCF shall send the response to the IP address indicated in the received 
parameter and to the port indicated in the rport parameter of the Via header associated with the UE. In case UDP 
is used as transport protocol, the P-CSCF shall use the port on which the REGISTER request was received as 
client port for sending the response back to the UE. 

When the P-CSCF receives a 401 (Unauthorized) response to a protected REGISTER request and that REGISTER 
request was protected by an old set of security associations that use UDP encapsulated tunnel mode, the P-CSCF shall: 

1) delete any temporary set of security associations established towards the UE; 

2) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the proper private 
user identity and to the temporary set of security associations which will be setup as a result of this challenge. 
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK have been 
removed; 

3) insert a Security-Server header in the response, containing the P-CSCF security list and the parameters needed 
for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPsec layer 
algorithms for integrity protection and encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall indicate 
"UDP-enc-tun" as the IPsec mode; 

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P- 
CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel 
mode and shall specify the same port_Uenc that was used in the old set of security associations. The P-CSCF 
shall set the temporary SIP level lifetime for the temporary set of security associations to the value of reg-await- 
auth timer; and 

5) send the 401 (Unauthorized) response to the UE using the old set of security associations. 

Otherwise, when the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request and this 
response does not contain a received and rport parameter or when the P-CSCF receives a 401 (Unauthorized) response 
to a protected REGISTER request and that REGISTER request was protected by an old set of security associations that 
do not use UDP encapsulated tunnel mode, the P-CSCF shall proceed as described in subclause 5.2.2 of the main body 
of this specification. 



F.3 Application usage of SDP 
F.3.1 UE usage of SDP 

The procedures as of subclause 6. 1 apply. 



F.3.2 P-CSCF usage of SDP 
F.3.2.1 Introduction 

Subclause F.3.2 describes the SDP related procedures performed by the P-CSCF in support of hosted NAT. 

F.3.2.2 Receipt of an SDP offer 

When the P-CSCF receives an SDP offer during session establishment, if this offer comes from a UE located behind a 
hosted NAT, the P-CSCF shall modify the SDP offer by replacing the IP address(es) and port number previously set in 
the SDP offer by the IP address(es) and port number(s) received from the IMS Access Gateway over the Iq interface. 
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F.3.2.3 Receipt of an SDP answer 



When the P-CSCF receives any SDP answer to an SDP offer described in subclause F.3.2.2, if this answer comes from 
a UE located behind a hosted NAT, the P-CSCF shall modify the SDP answer by replacing the IP address(es) and port 
number previously set in the SDP answer by the IP address(es) and port number(s) received from the IMS Access 
Gateway over the Iq interface. 

F.3.2.4 Change of media connection data 

After the session is established, it is possible for both ends of the session to change the media connection data for the 
session. When the P-CSCF receives a SDP offer/answer coming from a UE located behind a hosted NAT with port 
number(s) or IP address(es) included, there are three different possibilities: 

IP address(es) or/and port number(s) have been added. In this case, the P-CSCF shall apply the procedures as 
described in subclause F.3.2.2 and subclause F.3.2.3 as appropriate for those additional IP address(es) or/and 
port number(s); 

IP address(es) and port number(s) have been reassigned to the end points. In this case, the P-CSCF shall apply 
the procedures as described in subclause F.3.2.2 and subclause F.3.2.3 as appropriate for those reassigned IP 
address(es) and port number(s); 

NOTE: If necessary, the P-CSCF or IBCF will cause the IMS access gateway to release the resources related to 
the previously assigned IP address(es) and port number(s). 

no change has been made to the IP address(es) and port number(s). The P-CSCF shall apply procedures 
described in subclause F.3.2.2 using the previously stored IP address(es) and port number(s). 



F.4 P-CSCF usage of SIP in case UDP encapsulated 
IPsec is not employed 

F.4.1 Introduction 

This subclause describes the SIP procedures for supporting hosted NAT scenarios in case UDP encapsulated IPsec is 
not employed. In these scenarios the procedures for NAT traversal must take into account that all SIP requests and 
responses are not protected by an IPsec security association. 

F.4.2 Registration 

The procedures described in subclause 5.2.2 apply with the additional procedures described in the present clause. 

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall add the "received" and "rport" 
parameters to the Via header set to the source IP address and port of the packet header in accordance with the procedure 
defined in RFC 3261 [26] and RFC 3581 [56 A]. Furthermore, the P-CSCF performs the following actions on the 
Contact header depending on its content: 

if the Contact header contains a contact address in the form of an IP address (NOTE), the P-CSCF shall save this 
IP address for the duration of the registration and replace it by the source IP address of the packet containing the 
REGISTER request before forwarding the message; 

if the Contact header contains more than one contact addresses in the form of an IP address, the P-CSCF shall 
apply the above procedure to one of those contact addresses (i.e. by chosing the one with the hightest qvalue 
parameter) and delete any other contact addresses containing an IP address. 

Editor's note: Need to indicate what happens when two with same qvalue 

NOTE: When the host parameter in the Contact address is in the form of a FQDN, the P-CSCF has to ensure that 
the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP address and port pointing towards 
the hosted NAT and bound to this UE. 
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When the P-CSCF received a response to the above request, if the Contact header contains a contact address in the form 
of an IP address, the P-CSCF shall replace this IP address by the saved IP address contained in the REGISTER request 
before forwarding the associated response to the UE. 

F.4.3 General treatment for all dialogs and standalone 
transactions excluding the REGISTER method 

F.4.3. 1 Introduction 

The procedures described in subclause 5.2.6 apply with the additional procedures described in subclause F.2.3. 

F.4.3.2 Request initiated by the UE 

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, the P-CSCF shall add 
the "received" and "rport" parameters to the Via header set to the source IP address and port in the packet header as 
defined in RFC 3261 [26] and RFC 3581 [56A]. Furthermore, if the contact address in the Contact header is in the form 
of an IP address, the P-CSCF shall save this IP address for the duration of the dialog or standalone transaction and 
replace it by the source IP address of the packet containing the REGISTER request. 

When the P-CSCF received a response to the above request, if the Contact header contains a contact address in the form 
of an IP address, the P-CSCF shall replace this IP address by the saved IP address contained as per the previous 
paragraph. 

F.4.3. 3 Request terminated by the UE 

When the P-CSCF receives a response to an initial request for a dialog or a request for a standalone transaction, if the 
contact address in the Contact header is in the form of an IP address, the P-CSCF shall save this IP address for the 
duration of the dialog or standalone transaction and replace it by the source IP address of the packet containing the 
REGISTER request. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 356 ETSI TS 1 24 229 V7.6.0 (2006-1 2) 

Annex G (normative): 

Additional procedures in support of NA(P)T and NA(P)T-PT 

controlled by the P-CSCF 

NOTE: This subclause describes the mechanism for support of NA(P)T and NA(P)T-PT controlled by the P- 

CSCF scenario defined in 3GPP TS 23.228 [7]. This does not preclude other mechanisms but they are out 
of the scope of this annex. 

G.1 Scope 

This annex describes the P-CSCF procedures for supporting the scenario where IP address and/or port conversions 
occur at the IMS Access Gateway level in the media path between the UE and the backbone. Two types of address 
conversions are covered: 

IP version interworking (NA(P)T-PT); and; 

IP address/port translation (NA(P)T). 

The annex assumes that signalling procedure take place over the Iq interface to enable the P-CSCF to request and 
retrieve the address bindings reserved in the transport plane. 

Editor's note: It is for further study if the Iq reference point can be merged with the Rx+ reference point. If they are 
not merged then the IMS Access Gateway may be a TrGW and the Iq may be equivalent to the Ix 
reference point. 

Editor's Note: Different access architectures, possibly due to different access technologies, may need to be supported 
by the same P-CSCF. An understanding of the exact mechanism by which the P-CSCF determines 
whether the procedures described in the present annex is applicable for any individual session or not, is 
needed. 



G.2 P-CSCF usage of SDP 
G.2.1 Introduction 

The subclause G.2 describes the P-CSCF procedures for supporting IP address and/or port conversions in SDP that 
occur in the media path between the UE and the backbone. 

NOTE: In the particular case of RTP flows, port conversions also apply to the associated RTCP flows. 



G.2.2 Receipt of an SDP offer 



When the P-CSCF receives any SDP offer during session establishment, the P-CSCF shall modify the SDP offer by 
replacing the IP address(es) and port number previously set in the SDP offer by the IP address(es) and port number(s) 
received from the IMS Access Gateway over the Iq interface. 



G.2.3 Receipt of an SDP answer 



When the P-CSCF receives any SDP answer to an SDP offer described in subclause G.2.3, the P-CSCF shall modify the 
SDP answer by replacing the IP address(es) and port number previously set in the SDP answer by the IP address(es) and 
port number(s) received from the IMS Access Gateway over the Iq interface. 



ETSI 



3GPP TS 24.229 version 7.6.0 Release 7 357 ETSI TS 1 24 229 V7.6.0 (2006-1 2) 

The P-CSCF may receive multiple provisional responses with an SDP answer due to forking of a request before the first 
final answer is received. For each SDP answer received in such subsequent provisional responses, the P-CSCF shall 
apply the procedure in this subclause. 

G.2.4 Change of media connection data 

After the session is established, it is possible for both ends of the session to change the media connection data for the 
session. When the P-CSCF receives a SDP offer/answer where port number(s) or IP address(es) is/are included, there 
are three different possibilities: 

IP address(es) or/and port number(s) have been added. In this case, the P-CSCF shall apply the procedures as 
described in subclause G.2.2 or subclause G.2.3 as appropriate for those additional IP address(es) or/and port 
number(s); or 

IP address(es) and port number(s) have been reassigned to the end points. In this case, the P-CSCF shall apply 
the procedures as described in subclause G.2.2 or subclause G.2.3 as appropriate for those reassigned IP 
address(es) and port number(s); or 

NOTE: If necessary, the P-CSCF or IBCF will cause the IMS access gateway to release the resources related to 
the previously assigned IP address(es) and port number(s). 

no change has been made to the IP address(es) and port number(s). The P-CSCF shall apply procedures 
described in subclause G.2.2 using the previously stored IP address(es) and port number(s). 
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Annex H (normative): 

IP-Connectivity Access Network specific concepts when 

using DOCSIS to access IIVI CN subsystem 

H.1 Scope 

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) 
Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description 
Protocol (SDP), where the IP -CAN is a DOCSIS cable access network. 

DOCSIS (Data Over Cable Service Interface Specification) is a term referring to the ITU-T Recommendation J 112 [87] 
Annex B standard for cable modem systems. 

H.2 DOCSIS aspects when connected to the IIVI CN 
subsystem 

H.2.1 Introduction 

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the DOCSIS 
cable access network to provide packet-mode communication between the UE and the IM CN subsystem. 

From the perspective of the UE, the necessary IP -CAN bearer for signalling is transparently available to the UE. 

The UE is not directly involved in requests for IP -CAN bearer(s) for media flow(s). The IM CN interacts with the 
PCRF in the DOCSIS IP-CAN to establish IP-CAN bearer(s) for media flow(s), on behalf of the UE. 

H.2.2 Procedures at the UE 
H.2.2.1 P-CSCF discovery 

Prior to communication with the IM CN subsystem, the UE shall perform a Network Attachment procedure as defined 
in the CableLabs PacketCable specifications [88]. When using DOCSIS, both IPv4 and IPv6 UEs may access the IM 
CN subsystem. The procedures for P-CSCF discovery defined in subclause 9.2.1 of this document apply. 

H.2.2.2 Handling of tine IP-CAN 

The UE does not directly request resources for media flow(s). 

H.2. 2. 3 Special requirements applying to forked responses 

The UE does not directly request resources for media flow(s). As a result there are no special UE requirements applying 
to forked responses. 

H.2. 2. 4 Emergency service 

No particular requirements apply to emergency calls. 



£75/ 



3GPP TS 24.229 version 7.6.0 Release 7 359 ETSI TS 1 24 229 V7.6.0 (2006-1 2) 

H.3 Application usage of SIP 

H.3.1 Procedures at the UE 
H.3. 1.1 P-Access-Network-lnfo header 

If the UE is aware of the access technology, the UE shall include the P- Access-Network-Info header where indicated in 
subclause 5.1. 

H.3.2 Procedures at the P-CSCF 

Editor"s Note: If access specific part of subclause 5.2.10.1 is removed, the case when no MNC/MCC codes are 
available, must be described here. 
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Annex I (normative): 

Additional routing capabilities in support of transit traffic in 

IM CN subsystem 

1.1 Scope 

Operators may use the IM CN subsystem as a transit network to provide transit functionality for their own CS networks, 
enterprise networks, or other network operators. 

As specified in 3GPP TS 23.228 [7] additional routeing functions might reside in a stand-alone entity or might be 
collocated with the functionality of an MGCF, a BGCF, an I-CSCF, an S-CSCF, or an IBCF. 

When colocated with an I-CSCF, the additional routeing capabilities may be performed in advance of I-CSCF 
proecedures as specificed in subclause 5.3, or after I-CSCF procedures have failed to identify an S-CSCF supporting the 
user identified by the Request-URI. 

When colocated with an MGCF, the generated requests can be routed to an I-CSCF or to possible targets of the routeing 
procedures defined in subclause 1.2. 

The BGCF procedures specified in subclause 5.6 are a subset of the more general routeing procedures provided in this 
annex. 

NOTE: Depending on the host entity for the additional routeing functions, the functionality can be accessed as: 

a) the last set of functions on the host before forwarding a request (e.g., on an MGCF, an S-CSCF or an 
IBCF); 

b) the first set of functions performed by the host entity when receiving a request at the host entity's entry 
point (e.g., on a BGCF, I-CSCF or IBCF); 

c) a specified point in the logic of the host (e.g., on the I-CSCF at failure to identify an S-CSCF for the 
Request-URI); or 

d) a set of functions associated with a separate entry point (e.g., at a separate entry point associated with 
a BGCF, I-CSCF, IBCF or separate function). 

1.2 Procedures 

The additional routeing functionality, or associated functional entity, performing these additional routeing procedures 
should analyse the destination address, and determine whether to route to another network, possibly via the IBCF, or to 
the BGCF, or the I-CSCF in its own network. This analysis may use public (e.g., DNS, ENUM) and/or private database 
lookups, and/or locally configured data. 

When provided as a separate function, the network element performing these functions need not Record-Route the 
INVITE request. 

If the network element inserts its own Record-Route header, then it may require the periodic refreshment of the session 
to avoid hung states. If the network element requires the session to be refreshed, it shall apply the procedures described 
in RFC 4028 [58] clause 8. 

NOTE: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When provided as a separate function, the network element performing these functions shall not apply the procedures of 
RFC 3323 [33] relating to privacy. 
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Annex J (normative): 
CPC parameter definition 

J.1 Introduction 

This annex defines the use of the "CPC" URI parameter for use within SIP URI and Tel URI. 

Editor's note: This annex is based on draft-mahy-iptel-cpc-04.txt and can be removed when the internet draft 

becomes an RFC and the usage of the CPC is allowed for SIP URI. If this solution does not become an 
RFC, this parameter will be documented in the present document. 

Editor's note: It has to be clarified within the draft-mahy-iptel-cpc-04.txt that the CPC value belongs to the trust 
domain and shall not be populated by UE's 

The Calling Party's Category is represented as a tel URI parameter. The ABNF syntax is as follows: 

cpc = cpc-tag "=" cpc-value 

cpc-tag = "cpc" 

cpc-value 

= "ordinary" / "test" / "operator" / 

"payphone" / "unknown" / 

genvalue 

genvalue = 1* (alphanum / "-" / "." ) 

The Accept-Language header shall be used to express the language of the operator. 

The semantics of these Calling Party's Category values are described below: 

ordinary: The caller has been identified, and has no special features. 

test: This is a test call that has been originated as part of a maintenance procedure. 

operator: The call was generated by an operator position. 

payphone: The calling station is a payphone. 

unknown: The CPC could not be ascertained. 

NOTE 1 : The choice of CPC values and their use are up to the Service Provider. CPC values can be exchanged 
across networks if specified in a bilateral agreement between the service providers. 

NOTE 2: Additional national/regional CPC values may exist (e.g. prison, police, hotel, hospital, cellular, cellular- 
roaming., etc.) 



J. 2 Trust domain 



Entities in the IM CN subsystem shall restrict CPC tel URI or SIP URI parameter to specific domains that are trusted 
and support the CPC parameter. Therefore for the purpose of the CPC parameter within this specification, a trust 
domain also applies. This trust domain is identical to that of the P-Asserted-Identity. SIP functional entities within the 
trust domain will need to remove the CPC parameter when the contents of the P-Asserted-Identity header are inserted 
into the History-Info header. 

If the communication is to be passed to an untrusted network or a network not supporting the CPC parameter shall be 
removed. 
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J. 3 Procedures at the originating UE 

The CPC shall not be populated at the originating UE. 

J. 4 Procedures at the originating P-CSCF 

No special requirement. 

J. 5 Procedures at the originating S-CSCF 

No special requirement. 

J.6 Procedures at the l-CSCF 

No special requirement. 

J. 7 Procedures at the IBCF 

No special requirement. 

J. 8 Procedures at the terminating P-CSCF 

No special requirement. 

J. 9 Procedures at the AS at the originating network 

The AS may populate the CPC parameter in each initial request for a dialog or a request for a standalone transaction in 
the tel URI or SIP URI of the P-Asserted-Identity based on their origin source. 
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Annex K (normative): 

Additional procedures in support of UE managed NAT 

traversal 

K.1 Scope 

This annex describes the UE, P-CSCF, and S-CSCF procedures in support of UE managed NAT traversal. In this 
scenario, both the media flows and the SIP signalling both traverse a NA(P)T device located in the customer premises 
domain. The term "hosted NAT" is used to address this function. This annex does not consider the case where the NAT 
is behind the P-CSCF as different NAT traversal procedures are necessary for this architectural scenario. 

The procedures described in this subclause of this annex rely on the UE to manage the NAT traversal process. As part 
of the UE management process, the UE can learn whether it is behind a NAT or not, and choose whether the 
proceedures in this annex are applied or not. 

The protection of SIP messages is provided by applying UDP encapsulation to IPSec packets in accordance with 
RFC 3948 [63A] and as defined in 3GPP TS 33.203 [19]. 

NOTE 1 : This annex describes the mechanism for support of UE managed NAT traversal scenario defined in 

3GPP TS 23.228 [7]. This does not preclude other mechanisms but they are out of the scope of this annex. 

NOTE 2: It is recognized that outbound can be useful for capabilities beyond NAT traversal (e.g. multiple 

registrations) however this annex does not consider such capabilities at this time. Such capabilites can 
require additional information elements in the REGISTER request so that the P-CSCF and S-CSCF can 
distinguish whether to apply procedures as of annex F or annex K. 

K.2 Application usage of SIP 

Editors Note: Updates to affected tables in annex A.2 still need to be done. 

K.2.1 Procedures at the UE 
K.2.1.1 General 

This subclause describes the UE SIP procedures for supporting a UE managed hosted NAT traversal approach. The 
description enhances the procedures specified in subclause 5.1. 

K.2.1 .2 Registration ancj autinentication 
K.2.1. 2.1 General 

The text in subclause 5.1.1.1 applies without changes 

K.2.1 .2.1 A Parameters contained in the ISIM 

The text in subclause 5. 1.1.1 A applies without changes 

K.2.1. 2.2 Initial registration 

The procedures described in subclause 5.1.1.2 apply with the additional procedures described in the present subclause. 
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NOTE 1: In accordance with the definitions given in subclause 3.1 the IP address acquired initially by the UE in a 
hosted NAT scenario is the UE private IP address. 

On sending a REGISTER request, the UE shall populate the header fields as indicated in subitems a) through]) of 
subclause 5.1.1.2 with the exceptions of subitems d), e) and h) which are modified as follows 

The UE shall populate: 

d) a Contact header according to the following rules: the Contact header shall be set to include SIP URI(s) 
containing the private IP address of the UE in the hostport parameter or FQDN. The UE shall also include an 
instance ID and reg-id as described in draft-ieft-outbound [92]; 

e) a Via header according to the following rules: 

For UDP, if the REGISTER request is sent without integrity protection, the Via header shall be set to include 
the private IP address or FQDN of the UE in the sent-by field. If the REGISTER request is integrity 
protected, the UE shall include the public IP address or FQDN and the protected server port value in the sent- 
by field. In both cases the UE shall include the rport parameter as defined in RFC 3851[56A]; or 

For TCP, if the REGISTER request is sent without integrity protection, the Via header shall be set to include 
the private IP address or FQDN of the UE in the sent-by field. If the REGISTER request is integrity 
protected, the UE shall include the public IP address or FQDN; 

NOTE 2: The UE will learn its public IP address from the received parameter in the topmost Via header in the 401 
(Unauthorized) response to the unprotected REGISTER request. 

NOTE 3: If the UE specifies a FQDN in the host parameter in the Contact header and in the sent-by field in the Via 
header of an unprotected REGISTER request, this FQDN will not be subject to any processing by the P- 
CSCF or other IMS entities. 

h) the Security-Client header field set to specify the security mechanism the UE supports, the IPsec layer 

algorithms the UE supports and the parameters needed for the security association setup. The UE shall support 
the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters 
needed for the security association setup is specified in Annex H of 3GPP TS 33.203 [19]. The UE shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPSec layer 
algorithms for integrity protection and for encryption as defined in 3GPP TS 33.203 [19], and shall announce 
support for them according to the procedures defined in RFC 3329 [48]. In addition to transport mode the UE 
shall support UDP encapsulated tunnel mode as per RFC 3948 [63A] and shall announce support for both modes 
as described in 3GPP TS 33.203 [19]; 

When a 401 (Unauthorized) response to a REGISTER request is received and this response is received without integrity 
protection, the procedures described in subclause 5.1.1.2 apply with the following additions: 

The UE shall verify using the Security-Server header that mode "UDP-enc-tun" is selected. If the verification 
succeeds the UE shall behave as described in subclause K. 2. 1.2. 5. If the verification does not succeed the UE 
shall abort the registration. 

The UE shall check whether the outbound media tag is present in the supported header. 

If no outbound media tag is present, the UE shall refrain from registering additional Reg-IDs for the same private 
identity; or 

If an outbound media tag is present, the UE may establish a flow with each discovered P-CSCF as described in - 
ietf-sip-outbound [92]. 

Editors Note: The exact number of flows which the UE should register is for further study. 

When a 401 (Unauthorized) response to a REGISTER request is received with integrity protection the UE shall behave 
as described in subclause K.2.1.2.5. 

K.2.1 .2.3 Initial subscription to the registration-state event package 

The procedures described in subclause 5.1.1.3 apply with the additional procedures described in the present subclause. 
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On sending a SUBSCRIBE request, the UE shall populate the header fields as indicated in subclause 5.1.1.3 with the 
addition of subitem h) which is as follows 

The UE shall populate: 

h) a Via header according to the following rules: 

For UDP, the UE shall include the public IP address or FQDN and the protected server port value in the sent- 
by field. The UE shall also include the rport parameter as defined in RFC 3851 [56A]. The UE shall only use 
an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; or 

For TCP, the UE shall include the public IP address or FQDN of the UE in the sent-by field. The UE shall 
only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; 

K.2. 1.2.4 User-initiated re-registration 

The procedures described in subclause 5.1.1.4 apply with the additional procedures described in the present subclause. 

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as 
indicated in subclause 5.1.1.4 with the exception of subitems d) and e) which are modified as follows. 

The UE shall populate: 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the private IP address of the 
UE or FQDN, its instance ID along with the same Reg-ID used for the initial, successful, registration for the 
given P-CSCF public identity combination as described in -ietf-sip-outbound [92]; 

e) a Via header according to the following rules: 

For UDP, the UE shall include the public IP address or FQDN and the protected server port value in the sent- 
by field. The UE shall also include the rport parameter as defined in RFC 3851 [56A]. The UE shall only use 
an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; or 

For TCP, the UE shall include the public IP address or FQDN of the UE in the sent-by field. The UE shall 
only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; 

K.2.1.2.5 Authentication 
K.2.1. 2.5.1 General 

The procedures of subclause 5.1.1.5.1 apply with the additional procedures described in the present subclause. 

On receiving a 401 (Unauthorized) response to the REGISTER request and the response is deemed to be valid, the UE 
shall behave as of subclause 5.1.1.5.1 with the exception of subitem 3) which is modified as follows. 

The UE shall: 

3) send another REGISTER request using the temporary set of security associations to protect the message. The 
header fields are populated as defined for the initial request (see subclause K.2.1. 2. 2), with the addition that the 
UE shall include an Authorization header containing the private user identity and the authentication challenge 
response calculated by the UE using RES and other parameters, as described in RFC 3310 [49]. The UE shall 
also insert the Security-Client header that is identical to the Security-Client header that was included in the 
previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 
(Unauthorized) response). The UE shall also insert the Security-Verify header into the request, by mirroring in it 
the content of the Security-Server header received in the 401 (Unauthorized) response. The UE shall set the Call- 
ID of the integrity protected REGISTER request which carries the authentication challenge response to the same 
value as the Call-ID of the 401 (Unauthorized) response which carried the challenge. 

Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security 
associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The 
UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security 
associations. The UE should send an unprotected REGISTER request according to the procedure specified in 
subclause K.2.1. 2.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF. 
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K.2.1 .2.5.2 Network initiated re-authentication 

The procedures of subclause 5.1.1.5.2 apply with the additional procedures described in the present subclause. 

On starting the re-authentication procedure sending a REGISTER request that does not contain a challenge response, 
the UE shall behave as of subclause 5. 1 . 1 .5.2 with the exception of subitem 2) which is is modified as follows. 

The UE shall: 

2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure described in 
subclause 5.4.1.6) by initiating a re-registration as described in subclause K.2.1. 2.4, if required. 

K.2.1. 2. 5.3 Abnormal cases 

The text in subclause 5.1.1.5.3 applies without changes. 

K.2.1 .2.6 Change of IPv6 address due to privacy 

The text in subclause 5.1.1.5A applies without changes. 

K.2.1. 2. 7 User-initiated deregistration 

The procedures of subclause 5.1.1.6 apply with the additional procedures described in the present subclause. 

On sending a REGISTER request, the UE shall populate the header fields as indicated in subclause 5.1.1.6 with the 
exception of subitems d) and e) which are modified as follows. 

The UE shall populate: 

d) a Contact header set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP 
address of the UE or FQDN, its instance ID along with the same Reg-ID used for the initial, successful, 
registration for the given P-CSCF public identity combination as described in -ietf-sip-outbound [92];. The UE 
shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; 

e) a Via header according to the following rules: 

For UDP, the UE shall include the public IP address or FQDN and the protected server port value in the sent- 
by field. The UE shall also include the rport parameter as defined in RFC 3851 [56A]. The UE shall only use 
an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; or 

For TCP, the UE shall include the public IP address or FQDN of the UE in the sent-by field. The UE shall 
only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; 

NOTE: In case of hosted NAT traversal only the UE public IP addresses are bound to security associations. 

K.2.1. 2. 8 Network-initiated deregistration 

The procedures of subclause 5.1.1.7 apply with the additional procedures described in the present subclause. 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as 
described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE with: 

the state attribute set to "terminated" and the event attribute set to "rejected" or "deactivated"; or 

the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to 
"terminated", and associated event attribute element to "rejected" or "deactivated"; 

The UE shall remove all registration details relating to these public user identities. In case of a "deactivated" event 
attribute, the UE shall start the initial registration procedure as described in subclause K.2.1. 2. 2. In case of a "rejected" 
event attribute, the UE shall release all dialogs related to those public user identities. 
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K.2.1 .3 Subscription and notification 

The text in subclause 5.1.2 applies without changes. 

K.2.1 .4 Generic procedures applicable to all methods excluding the 
REGISTER method 

K.2.1 .4.1 UE originating case 

The procedures described in subclause 5.1.2A.1 apply with the additional procedures described in the present subclause. 

When the UE sends any request, the requirements in subclause 5.1.2A. 1 are extended by the following requirements. 
The UE shall include: 

a Via header according to the following rules: 

For UDP, the UE shall include the public IP address or FQDN and the protected server port value in the sent- 
by field. The UE shall also include the rport parameter as defined in RFC 3851 [56A]. The UE shall only use 
an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; or 

- For TCP, the UE shall include the public IP address or FQDN of the UE in the sent-by field. The UE shall 
only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; and 

the private IP address of the UE or FQDN in the hostport parameter in any Contact header that is otherwise 
included. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the 
NAT. 

The UE shall discard any SIP response that is not integrity protected and is received from the P-CSCF outside of the 
registration and authentication procedures. The requirements on the UE within the registration and authentication 
procedures are defined in subclause K.2. 1.2.4. 

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F 
expired, as described in subclause K.2.1. 2. 3. 

K.2.1 .4.2 UE terminating case 

The procedures described in subclause 5. 1.2 A. 2 apply with the additional procedures described in the present subclause. 

When the UE sends any response, the requirements in subclause 5.1.2A.1 are extended by the following requirement. 
The UE shall: 

include the private IP address of the UE or FQDN in the hostport parameter in any Contact header that is 
otherwise included. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP 
address of the NAT. 

The UE shall discard any SIP request that is not integrity protected and is received from the P-CSCF outside of the 
registration and authentication procedures. The requirements on the UE within the registration and authentication 
procedures are defined in subclause K.2. 1 .2. 

K.2.1 .5 Maintaining flows and detecting flow failures 

STUN Binding Requests are used by the UE as a keep-alive mechanism to maintain NAT bindings for signaling flows 
(for dialogs outside a registration as well as within a registration) as well as to determine whether a flow (as described 
in -ietf-sip-outbound [92]) is still valid (e.g. a NAT reboot could cause the transport parameters to change). As such, the 
UE acts as a STUN client and shall follow the requirements defined by draft-ietf-behave-rfc3489bis [100]. Further, 
when using UDP encapsulated IPsec, the keep-alive capabilities defined within should not be used. 

If the UE determines that the flow to a given P-CSCF is no longer valid (the UE does not receive a STUN reply or the 
reply indicates a new public IP Address) the UE shall consider the flow and any associated security associations invalid 
and perform the initial Registration procedures defined in K.2.1. 2.2. 
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When a NAT is not present, it may not be desirable to send keep-alive requests (i.e. given battery considerations for 
wireless UEs). As such, if a UE can reliably determine that a NAT is not present (i.e. by comparing the "received" and 
"rport" parameters in the Via header in the response to the initial un-protected REGISTER request with the locally 
assigned IP Address and Port) then the UE may not perform the keep-alive procedures. 

K.2.2 Procedures at the P-CSCF 
K.2.2.1 Introduction 

This subclause describes the SIP procedures for supporting hosted NAT scenarios. 
The description enhances the procedures specified in subclause 5.2. 

K.2.2.2 Registration 

The procedures described in subclause 5.2.2 apply with the additional procedures described in the present subclause. 

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall behave as of subclause 5.2.2 with the 
exception of subitems 1), 5), and 6) which are modified as follows. 

The P-CSCF shall: 

1) insert a Path header in the request including an entry containing: 

- the SIP URI identifying the P-CSCF; 

an indication that requests routed in this direction of the path (i.e. from the S-CSCF to the P-CSCF) are 
expected to be treated as for the mobile-terminating case. This indication may e.g. be in a parameter in the 
URI, a character string in the user part of the URI, or be a port number in the URI; 

a flow identifier token as described in draft-ietf-sip-outbound [92]; 

NOTE 1 : Outbound describes two informational algorithms for generating a flow token. Both algorithms assume 
that the UE and the P-CSCF use symmetric ports to transmit and receive SIP signalling. Given the 
defined usage of IPsec, these algorithms are not applicable (3GPP TS 33.203 [19] requires the use of 
different ports to transmit and receive SIP signalling). As such the P-CSCF will need to implement an 
algorithm which generates a flow token which identifies the flow to the UEs protected server port, rather 
then the flow which the REGISTER request was received on. 

5) in case the REGISTER request was received without integrity protection, then: 

a) check the existence of the Security-Client header. If the header is not present, then the P-CSCF shall return a 
suitable 4xx response. If the header is present the P-CSCF shall: 

in case the UE indicated support for "UDP-enc-tun" then remove and store it; or 

in case the UE does not indicate support for "UDP-enc-tun" then: 

if the host portion of the sent-by field in the topmost Via header contains an IP address that differs 
from the source address of the IP packet, silently drop the REGISTER request; 

otherwise continue with procedures as of subclause 5.2.2; 

NOTE 2: If the UE does not indicate support for "UDP-enc-tun" and the P-CSCF detects that the UE is located 
behind a NAT device, then the P-CSCF can just drop the REGISTER request to avoid unnecessary 
signalling traffic. 

b) if the host portion of the sent-by field in the topmost Via header contains a FQDN, or if it contains an IP 
address that differs from the source address of the IP packet, the UE is assumed to be behind a NAT and the 
P-CSCF shall add a received parameter in accordance with the procedure defined in RFC 3261 [26]. If the P- 
CSCF adds a received parameter, it shall also add an rport parameter in accordance with the procedure 
defined in RFC 3581 [56A] and remember that the UE is behind a NAT; 
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6) in case the REGISTER request was received integrity protected, then the P-CSCF shall: 

a) check the security association which protected the request. If the security association is a temporary one, the 
P-CSCF shall: 

in case the host parameter in the Contact address is in the form of a FQDN, ensure that the given FQDN 
will resolve (e.g., by reverse DNS lookup) to the IP address bound to the security association; 

in case the P-CSCF has detected earlier that the UE is located behind a NAT, retrieve port_Uenc from the 
encapsulating UDP header of the packet received and complete configuration of the temporary set of 
security associations by configuring port_Uenc in each of the temporary security associations; 

check whether the request contains a Security- Verify header in addition to a Security-Client header. If 
there are no such headers, then the P-CSCF shall return a suitable 4xx response. If there are such headers, 
then the P-CSCF shall compare the content of the Security- Verify header with the content of the Security- 
Server header sent earlier and the content of the Security-Client header with the content of the Security- 
Client header received in the challenged REGISTER request. If those do not match, then there is a 
potential man-in-the-middle attack. The request should be rejected by sending a suitable 4xx response. If 
the contents match, the P-CSCF shall remove the Security-Verify and the Security-Client header; 

b) process the Via header according to the following rules: 

If the host portion of the sent-by field in the topmost Via header contains a FQDN, or if it contains an IP 
address that differs from the source address of the IP packet, the P-CSCF shall add a received parameter 
in accordance with the procedure defined in RFC 3261 [26]; 

If the P-CSCF adds a received parameter and UDP is being used, it shall also add an rport parameter with 
the UEs protected server port; 

When the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request and the P-CSCF 
previously determined that the UE is behind a NAT and the UE indicated support for "UDP-enc-tun" IPsec mode, the P- 
CSCF shall: 

1) delete any temporary set of security associations established towards the UE; 

2) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the proper private 
user identity and to the temporary set of security associations which will be setup as a result of this challenge. 
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK have been 
removed; 

3) insert a Security-Server header in the response, containing the P-CSCF security list and the parameters needed 
for the security association setup, as specified in annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPSec layer 
algorithms for integrity protection and for encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall 
indicate "UDP-enc-tun" as the only IPsec mode; 

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P- 
CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel 
mode and shall leave the value for port-Uenc unspecified in each of the temporary security associations. For 
further details see 3GPP TS 33.203 [19] and RFC 3329 [48]. The P-CSCF shall set the temporary SIP level 
lifetime for the temporary set of security associations to the value of reg-await-auth timer; and 

5) send the 401 (Unauthorized) response unprotected to the UE using the mechanisms described in RFC 3261 [26] 
and RFC 3581 [56A], i.e. the P-CSCF shall send the response to the IP address indicated in the received 
parameter and to the port indicated in the rport parameter (if present) of the Via header associated with the UE. 
In case UDP is used as transport protocol, the P-CSCF shall use the port on which the REGISTER request was 
received as client port for sending the response back to the UE. 

When the P-CSCF receives a 401 (Unauthorized) response to a protected REGISTER request and the P-CSCF 
previously determined that the UE is behind a NAT and that REGISTER request was protected by an old set of security 
associations that use UDP encapsulated tunnel mode, the P-CSCF shall: 

1) delete any temporary set of security associations established towards the UE; 
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2) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the proper private 
user identity and to the temporary set of security associations which will be setup as a result of this challenge. 
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK have been 
removed; 

3) insert a Security-Server header in the response, containing the P-CSCF security list and the parameters needed 
for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPsec layer 
algorithms for integrity protection and encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall indicate 
"UDP-enc-tun" as the IPsec mode; 

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P- 
CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel 
mode and shall specify the same port_Uenc that was used in the old set of security associations. The P-CSCF 
shall set the temporary SIP level lifetime for the temporary set of security associations to the value of reg-await- 
auth timer; and 

5) send the 401 (Unauthorized) response to the UE using the old set of security associations using the mechanisms 
described in RFC 3261 [26] and RFC 3581 [56A], i.e. the P-CSCF shall send the response to the IP address 
indicated in the received parameter and to the port indicated in the rport parameter (if present) of the Via header 
associated with the UE. Otherwise, when the P-CSCF receives a 401 (Unauthorized) response to an unprotected 
REGISTER request and this response does not contain a received and rport parameter or when the P-CSCF 
receives a 401 (Unauthorized) response to a protected REGISTER request and that REGISTER request was 
protected by an old set of security associations that do not use UDP encapsulated tunnel mode, the P-CSCF shall 
proceed as described in subclause 5.2.2 of the main body of this specification. 

K.2.2.3 General treatment for all dialogs and standalone transactions 
excluding the REGISTER method 

K.2.2.3. 1 Requests initiated by the UE 

The procedures described in subclause 5.2.6.3 apply with the additional procedures described in the present subclause. 

When the P-CSCF receives from the UE a request method other then a REGISTER request, and a Service-Route header 
list exits for the initiator of the request, the requirements are extended by the following requirements. 

The P-CSCF shall: 

process the Via header according to the following rules: 

If the host portion of the sent-by field in the topmost Via header contains a FQDN, or if it contains an IP 
address that differs from the source address of the IP packet, the P-CSCF shall add a received parameter 
in accordance with the procedure defined in RFC 3261 [26]; 

If the P-CSCF adds a received parameter and UDP is being used, it shall also add an rport parameter with 
the UEs protected server port; 

Before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 
3261 [26], the P-CSCF shall ensure that all signalling during the lifetime of the dialogue is sent over the same 
flow (source IP and Port/destination IP and Port) as the dialogue initiating request. 

NOTE: The suggested way to ensure all signaling is sent over the same flow is to form a flow identifier token in 
the same way that a P-CSCF would form this for the Path header and insert this flow identifier token in 
the user portion of the URI used in the record route header field value. 

When the P-CSCF receives a Ixx or 2xx response to the above request, the requirements are extended by the following 
requirements. The P-CSCF shall: 

Forward the response to the UE using the mechanisms described in RFC 3261 [26] and RFC 3581 [56A], i.e. the 
P-CSCF shall send the response to the IP address indicated in the received parameter and to the port indicated in 
the rport parameter (if present) of the Via header associated with the UE. 
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K.2.2.3.2 Requests terminated by the UE 

The procedures described in subclause 5.2.6.4 apply with the additional procedures described in the present subclause. 

When the P-CSCF receives, destine for the UE, a request method other then a REGISTER request, the requirements are 
extended by the following requirements. The P-CSCF shall: 

Forward the request to the terminating UEs protected server port over the flow identified by the flow identifier 
token in the route header as defined in draft-ietf-sip-outbound [92]. 

NOTE: The above requirement represents a deviation from the outbound draft as outbound requires that the 

request be forwarded on the flow which the REGSITER was received on. This cannot be done per 3GPP 
TS 33.203 [19] requirements to use asymmetric ports for IPsec. 

K.2.2.4 STUN server support 

To support UE keep-alive procedures, the P-CSCF shall also support the requirements for a STUN server as defined by 
draft-ietf-behave-rfc3489bis [100]. The STUN server shall use the same signaling port that is used for SIP. 

K.2.3 Procedures at the S-CSCF 
K.2.3.1 Registration and authentication 
K.2.3.1.1 Introduction 

The procedures described in subclause 5.4.1.1 apply with the additional procedures described in the present subclause 

K.2.3. 2 Initial registration and user-initiated re-registration 
K.2.3.2.1 Unprotected REGISTER 

The procedures described in subclause 5.4.1.2.1 apply with the additional procedures described in the present subclause. 

Upon receipt of a REGISTER request without an "integrity-protected" parameter, or with the "integrity-protected" 
parameter in the Authorization header set to "no", for a user identity linked to a private user identity that has a registered 
public user identity but with a new contact address, the S-CSCF shall follow the procedures described in subitem 1) and 
2) which is modified as follows: 

2) if the authentication has been successful and if the previous registration has not expired, the S-CSCF shall 
determine if the contact address contains a reg-id and instance-id in the received contact header. If the 
parameters are present, the S-CSCF shall follow the requirements defined in draft-ietf-sip-outbound [92]. If the 
parameters are not present, the S-CSCF shall perform the network initiated deregistration procedure only for the 
previous contact information as described in subclause 5.4.1.5. 

Upon receipt of a REGISTER request without an "integrity-protected" parameter, or with the "integrity-protected" 
parameter in the Authorization header set to "no", which is not for an already registered public user identity linked to 
the same private user identity, the S-CSCF shall follow the procedures described in subitems 1) through 8) with the 
addition of subitem 6b) which is as follows: 

6b) a Supported header with the "outbound" option-tag as described in draft-ietf-sip-outbound [92] 

K.2.3.2.2 Protected REGISTER 

The procedures described in subclause 5.4.1.2.2 apply with the additional procedures described in the present subclause. 

Upon receipt of a REGISTER request with the 'integrity-protected' parameter in the Authorization header set to 'yes' and 
the timer reg-await-auth is running the S-CSCF shall follow the procedures as described in all subitems with the additon 
of subitem 1 1) h) which is as follows: 

h) a Supported header with the "outbound" option-tag as described in draft-ietf-sip-outbound [92]; 
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K.2.3.3 General treatment for all dialogs and standalone transactions 
excluding requests terminated by the S-CSCF 

K.2.3.3. 1 Determination of mobile-originated or mobile terminated case 

The text in subclause 5.4.3.1 applies without changes 

K.2.3.3. 2 Requests initiated by the served user 

The text in subclause 5.4.3.2 applies without changes 

K.2.3.3. 3 Requests terminated by the served user 

The procedures described in subclause 5.4.3.3 apply with the additional procedures described in the present subclause. 

When the S-CSCF receives, destined for a statically pre-configured PSI or a registered served user, an initial request for 
a dialog or a request for a standalone transaction, prior to forwarding the request, the S-CSCF shall follow all the 
procedures as describes with the exception of subitem 10) a) which is modified as follows: 

10)in case there are no Route headers in the request, the S-CSCF shall: 

a) if there is more than one route in the target set determined in steps 8) and 9) above, the S-CSCF shall: 

if the fork directive in the Request Disposition header was set to "no-fork", the contact with the highest 
qvalue parameter shall be used when building the Request-URL In case no qvalue parameters were 
provided, the S-CSCF shall decide locally what contact address to be used when building the Request- 
URI; otherwise 

fork the request or perform sequential search based on the relative preference indicated by the qvalue 
parameter of the Contact header in the original REGISTER request, as described in RFC 3261 [26]. In 
case no qvalue parameters were provided, then the S-CSCF determine the contact address to be used 
when building the Request-URI as directed by the Request Disposition header as described in RFC 3841 
[56B]. If the Request-Disposition header is not present, the S-CSCF shall decide locally whether to fork 
or perform sequential search among the contact addresses; 

in case that no route is chosen, the S-CSCF shall return a 480 (Temporarily unavailable) response or 
another appropriate unsuccessful SIP response and terminate these procedures. 

Per the rules defined in draft-ietf-sip-outbound [92], the S-SCSF shall not populate the target set with 
more than one contact with the same AOR and instance-id at a time. If a request for a particular AOR and 
instance-id fails with a 410 response, the S-CSCF shall replace the failed branch with another target with 
the same AOR and instance-id, but a different reg-id; 

If two bindings have the same instance-id and reg-id, it should prefer the contact that was most recently 
updated; 



K.3 Application usage of SDP 
K.3.1 UE usage of SDP 

The procedures as of subclause 6. 1 apply. 
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K.3.2 P-CSCF usage of SDP 
K.3.2.1 Introduction 

Subclauses K.3.2. 2 through K.3.2. 4 describe the SDP related procedures performed by the P-CSCF in support of hosted 

NAT. 

K.3.2.2 Receipt of an SDP offer 

When the P-CSCF receives an SDP offer during session establishment, if this offer comes from a UE which does not 
support the procedures defined in subclause K.5.2.1 and is located behind a hosted NAT, the P-CSCF shall modify the 
SDP offer by replacing the IP Address(es) and port number previously set in the SDP offer by the IP address(es) and 
port number(s) received from the IMS Access Gateway over the Iq interface. 

NOTE: The P-CSCF can determine if the UE supports the ICE procedures covered in section K.5.2.1 by the 
presence of a=candidate attributes in the SDP. 

Editors Note: P-CSCF handling of a=candidate attributes in the SDP when the P-CSCF chooses to modify the SDP 
offer by replacing the IP Address(es) and port number previously set in the SDP offer by the IP 
address(es) and port number(s) received from the IMS Access Gateway over the Iq interface. 

K.3.2.3 Receipt of an SDP answer 

When the P-CSCF receives any SDP answer to an SDP offer described in subclause K.5.2.1, if this answer comes from 
a UE which does not support the procedures defined in subclause K.5.2.2 and is located behind a hosted NAT, the P- 
CSCF shall modify the SDP answer by replacing the IP address(es) and port number previously set in the SDP answer 
by the IP address(es) and port number(s) received from the IMS Access Gateway over the Iq interface. 

NOTE: The P-CSCF can determine if the UE supports the ICE procedures covered in section K.5.2.1 by the 
presence of a=candidate attributes in the SDP. 

Editors Note: P-CSCF handling of a=candidate attributes in the SDP when the P-CSCF chooses to modify the SDP 
offer by replacing the IP Address(es) and port number previously set in the SDP answer by the IP 
address(es) and port number(s) received from the IMS Access Gateway over the Iq interface. 

K.3.2. 4 Cinange of media connection data 

After the session is established, it is possible for both ends of the session to change the media connection data for the 
session. When the P-CSCF receives a SDP offer/answer coming from a UE located behind a hosted NAT with port 
number(s) or IP address(es) included, there are three different possibilities: 

IP address(es) or/and port number(s) have been added. In this case, the P-CSCF shall apply the procedures as 
described in subclause K.3.2.2 and subclause K.3.2.3 as appropriate for those additional IP address(es) or/and 
port number(s); 

IP address(es) and port number(s) have been reassigned to the end points. In this case, the P-CSCF shall apply 
the procedures as described in subclause K.3.2.2 and subclause K.3.2.3 as appropriate for those reassigned IP 
address(es) and port number(s); 

NOTE: If necessary, the P-CSCF or IBCF will cause the IMS access gateway to release the resources related to 
the previously assigned IP address(es) and port number(s). 

no change has been made to the IP address(es) and port number(s). The P-CSCF shall apply procedures 
described in subclause K.3.2.2 using the previously stored IP address(es) and port number(s). 
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K.4 P-CSCF usage of SIP in case UDP encapsulated 
IPsec is not employed 

K.4.1 Introduction 

The procedures defined in subclauses K.2 and K.3 remain unchanged when supporting hosted NAT scenarios in case 
UDP encapsulated IPsec is not employed. In these scenarios the procedures for NAT traversal must take into account 
that all SIP requests and responses are not protected by an IPsec security association. 

K.5 Application usage of ICE 

Editors Note: Updates to affected tables in Annex A. 3 still need to be done. 

K.5.1 Introduction 

The following subclauses describe a UEs usage of the Interactive Connectivity Establishment (ICE) procedures as 
documented in draft-ietf-mmusic-ice [99] 

K.5.2 UE usage of ICE 
K.5.2.1 General 

NAT bindings also need to be kept alive for media, draft-ietf-mmusic-ice [99] provides requirements for STUN based 
keepalive mechanisms. UEs that do not implement the ICE procedures as defined in draft-ietf-mmusic-ice [99] should 
implement the keepalive procedures defined in draft-ietf-mmusic-ice [99]. In the case where keepalives are required and 
the other end does not support ICE (such that STUN cannot be used for a keepalive), the UE shall send an empty (no 
payload) RTP packet with a payload type of 20 as a keepalive as long as the other end has not negotiated the use of this 
value. If this value has already been negotiated, then some other unused static payload type from Table 5 of RFC 3551 
[89] shall be used. When sending an empty RTP packet, the UE shall continue using the sequence number (SSRC) and 
timestamp as the negotiated RTP steam. 

K.5. 2. 2 Call initiation - UE-origination case 

The UE should support the agent requirements for ICE as defined by draft-ietf-mmusic-ice [99] when sending the initial 
INVITE request, draft-ietf-mmusic-ice [99] provides procedures for: 

1) Gathering candidate addresses for RTP and RTCP prior to sending the INVITE; 

2) Encoding the candidate addresses in the SDP that is included with the INVITE; 

3) Acting as a STUN server to receive binding requests from the remote client when it does connectivity checks; 

4) Performing connectivity checks on received candidate addresses for RTP and RTCP; 

5) Determining and possibly selecting a better active address based on the requirements in draft-ietf-mmusic- 
ice [99]; 

6) Subsequent offer/answer exchanges; and 

7) Sending media. 

When supporting the ICE procedures, the UE shall also support the STUN agent requirements as described in draft-ietf- 
behave-rfc3489bis [100] in order to gather STUN addresses, the STUN Relay client requirements as described in draft- 
ietf -behave -turn [101] in order to gather STUN Relay Server addresses and the STUN Server requirements defined in 
draft-ietf-mmusic-ice [99] as well as the requirements for STUN Servers defined in draft-ietf-behave-rfc3489bis [100] 
for responding to connectivity checks. 
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Draft-ietf-mmusic-ice [99] does not including any normative requirements for prioritizing address candidates and 
selecting the active transport address. The requirements for the UE are specified as follows: 

1) If a STUN relay server is available, the Relayed Transport Address should be used as the initial active transport 
address (i.e., as advertised in the m/c lines of the SDP); 

2) If a STUN relay server is not available, an address obtained via STUN should be used as the initial active 
transport address; 

3) The priority of candidate addresses from least to highest should be: Relayed Transport Address, STUN address, 
local address; and 

4) If the UE has a dual IPv4/IPv6 stack, IPv6 addresses may be placed at a higher priority than IPv4 addresses 
based on the operator's policy. 

Regardless of whether the UE supports the above procedures, the UE shall, upon receipt of an SDP answer with 
candidate addresses, perform connectivity checks on the candidate addresses as described in draft-ietf-mmusic-ice [99]. 
In order to perform connectivity checks, the UE shall act as a STUN client as defined in draft-ietf-behave- 
rfc3489bis [100]. Further, the UE shall also follow the procedures in draft-ietf-mmusic-ice [99] when sending media. 

K.5.2.3 Call termination - UE-termination case 

The UE should support agent requirements for ICE as defined by draft-ietf-mmusic-ice [99] when receiving an initial 
INVITE request, draft-ietf-mmusic-ice [99] provides procedures for: 

1) Gathering candidate addresses for RTP and RTCP prior to sending the answer as described in draft-ietf-mmusic- 
ice [99]; 

2) Encoding the candidate addresses in the SDP answer as described in draft-ietf-mmusic-ice [99]; 

3) Acting as a STUN server to receive binding requests from the remote client when it does connectivity checks; 

4) Performing connectivity checks on received candidate addresses for RTP and RTCP; 

5) Determining and possibly selecting a better active address based on the requirements in draft-ietf-mmusic- 
ice [99]; 

6) Subsequent offer/answer exchanges; and 

7) Sending media. 

When supporting the ICE procedures, the UE shall also support the STUN agent requirements as described in draft-ietf- 
behave-rfc3489bis [100] in order to gather STUN addresses, the STUN Relay client requirements as described in draft- 
ietf-behave-turn [101] in order to gather STUN Relay Server addresses and the STUN Server requirements defined in 
draft-ietf-mmusic-ice [99] as well as the requirements for STUN Servers defined in draft-ietf-behave-rfc3489bis [100] 
for responding to connectivity checks. 

Draft-ietf-mmusic-ice [99] does not including any normative requirements for prioritizing address candidates and 
selecting the active transport address. The requirements for the UE are specified as follows: 

1) If a STUN relay server is available, the Relayed Transport Address should be used as the initial active transport 
address (i.e., as advertised in the m/c lines of the SDP); 

2) If a STUN relay server is not available, an address obtained via STUN should be used as the initial active 
transport address; 

3) The priority of candidate addresses from least to highest should be: Relayed Transport Address, STUN address, 
local address; and 

4) If the UE has a dual IPv4/IPv6 stack, IPv6 addresses MAY be placed at a higher priority than IPV4 addresses 
based on the operator's policy. 

Regardless of whether the UE supports the above procedures, the UE shall, upon receipt of an SDP offer with candidate 
addresses, perform connectivity checks on the candidate addresses as described in draft-ietf-mmusic-ice [99]. In order 
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